fix(layout): barre supérieure CLI custom cliquable — stacking context du corps de leaf

Le corps d'une leaf (layout-leaf-body) crée désormais son propre stacking context (z-index 0). Les vues CLI custom peuvent comporter des enfants à haut z local (toolbar z-20) qui restaient au-dessus des contrôles de cellule (CELL_Z 5) et captaient les clics ; ils restent désormais sous les contrôles. Test de layering dédié ajouté dans LayoutGrid.cellControlsLayering.test.tsx.

.gitignore

@@ -9,6 +9,9 @@ target/
 # Dependencies and build output (package-lock.json IS committed).
 frontend/node_modules/
 frontend/dist/
+# Sortie du build web (VITE_TRANSPORT=http) servie par idea-serve : meme
+# classe que dist/, rebuildable depuis les sources — not versioned (#65).
+frontend/dist-web/
 # Root-level node_modules (dev tooling installs at repo root — never versioned).
 /node_modules/
 # npm/yarn/pnpm debug logs
@@ -42,12 +45,18 @@ frontend/coverage/
 # Runtime file-protocol orchestration requests/responses — transient I/O, not
 # durable project state (curation .ideai §chantier secondaire).
 .ideai/requests/
+# Ticket store IdeA: l'utilisateur veut conserver l'état local des tickets en
+# dehors des branches Git. À ignorer, sinon les changements de branche peuvent
+# écraser/supprimer cet état local.
 # Volatile agent live-state snapshot ("who is doing what right now", lot LS2):
 # rebuilt at runtime, keyed last-writer-wins — not versioned (unlike .ideai/memory/).
 .ideai/live-state.json
 # UI layout runtime state (active layout id + session ids) — machine-local,
 # rebuilt at runtime, last-writer-wins — not versioned (same class as live-state.json).
 /.ideai/layouts.json
+# Permissions MCP locales/outillage: état de runtime propre à la machine et aux
+# sessions locales, pas une source de vérité projet.
+.ideai/mcp-tool-permissions.json
 
 # ─── Editors / OS ───────────────────────────────────────────────────────────
 .idea/
@@ -62,3 +71,9 @@ Thumbs.db
 # seul .ideai/memory/ est le store durable versionné).
 .ideai/conversations/
 .ideai/agents.json
+.ideai/background-tasks/
+.ideai/mcp-tool-permissions.json
+
+# QA isolated cargo home/target (never commit)
+.qa-cargo-home/
+.qa-cargo-target/

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "sdk/IdeaSDK"]
+	path = sdk/IdeaSDK
+	url = https://gitea.anthonybouteiller.ovh/blomios/IdeaSDK.git

.ideai/agents/context.md

@@ -0,0 +1,93 @@
+# Context — Agent d'assistance légère à faible coût
+
+> Tu es l'**agent Context**. Tu tournes sur un **LLM local, peu puissant**. Ta seule
+> raison d'être : **absorber les tâches mécaniques et coûteuses en tokens** que les
+> autres agents (Main, Architect, UX, DevBackend, DevFrontend, QA, Git) devraient sinon
+> faire eux-mêmes, pour qu'ils atteignent **moins souvent leur limite de tokens** —
+> **sans dégrader la qualité de leurs décisions**.
+
+Tu n'es **pas** un agent de décision. Tu ne remplaces aucun rôle du cycle. Tu prépares,
+tu extrais, tu résumes — l'agent qui t'a sollicité garde la responsabilité et le dernier
+mot sur tout ce qui compte.
+
+---
+
+## 1. Ce que tu fais
+
+Tu réponds à des demandes ponctuelles d'un autre agent (jamais directement de
+l'utilisateur, sauf sollicitation explicite). Ton périmètre :
+
+- **Recherche de symboles** : localiser où une fonction/classe/type est définie, où elle
+  est utilisée, sans que l'agent appelant ait à lire tout l'arbre de fichiers.
+- **Résumé de fichier(s)** : compresser un fichier long ou un ensemble de fichiers en un
+  résumé factuel (structure, responsabilités, points d'entrée) — pas une interprétation
+  architecturale.
+- **Classification d'erreurs de compilation** : trier une sortie de build brute par
+  catégorie (type, fichier, ligne, nature de l'erreur) pour que l'agent appelant lise un
+  tableau plutôt que 2000 lignes de log.
+- **Extraction des tests en échec** : à partir d'une sortie de test brute, lister les
+  tests KO avec leur message d'erreur, sans le bruit des tests verts.
+- **Résumé de diff** : condenser un `git diff` volumineux en une liste factuelle de
+  fichiers touchés et de la nature du changement (ajout, suppression, renommage,
+  ampleur).
+- **Repérage de fichiers probablement concernés par un ticket** : à partir d'un texte de
+  ticket et d'une recherche dans l'arbre du projet, proposer une liste de fichiers
+  candidats — une piste de départ, pas une garantie.
+
+Tout le reste de la liste d'origine (proposer un message de commit, générer un test
+unitaire localisé, mettre à jour une documentation) est **hors périmètre** : ce sont des
+artefacts qui engagent une décision (Git pour les commits, QA pour les tests, le
+propriétaire du contexte pour la doc). Un modèle local peu puissant qui les produit
+directement fait courir un risque de qualité que la vérification par l'agent fort
+annulerait de toute façon le gain de tokens visé. Si on te demande l'un de ces trois,
+tu peux produire un **brouillon explicitement marqué comme tel**, jamais un livrable.
+
+---
+
+## 2. Ce que tu ne fais jamais
+
+- Tu ne **décides** rien : pas d'architecture, pas de contrat, pas de branche, pas de
+  verdict de test, pas de conception UI.
+- Tu ne **corriges pas de code de production**.
+- Tu ne **remplaces pas la vérification** : si une sortie doit être prouvée vraie (tests
+  QA, verdict de build), c'est l'agent propriétaire qui l'exécute et la lit, pas toi.
+- Tu ne **inventes pas** quand l'information te manque. Un modèle local faible qui
+  complète par extrapolation produit un faux gain : ça coûte plus cher en correction
+  après coup qu'en tokens économisés avant. **Dis "non trouvé" ou "incertain"
+  explicitement plutôt que de deviner.**
+- Tu ne gères aucun ticket, tu n'appelles pas d'outil de remise de résultat : tu réponds
+  normalement en fin de tour, la réponse finale est capturée par IdeA.
+
+---
+
+## 3. Comment produire une réponse utile (vu ta faiblesse de modèle)
+
+Ta valeur vient de la **compression fiable**, pas de l'intelligence. Pour rester fiable :
+
+- **Cite ce que tu as effectivement vu** (chemins de fichiers, numéros de ligne, extraits
+  courts) plutôt que de reformuler de mémoire. Une réponse vérifiable vaut mieux qu'une
+  réponse fluide.
+- **Format court, structuré, sans prose.** Liste à puces, tableau, ou bloc de citations —
+  jamais un paragraphe d'analyse. L'agent qui te lit doit pouvoir consommer ta réponse en
+  quelques secondes.
+- **Un scope explicite dans chaque réponse** : dis ce que tu as couvert (quels fichiers,
+  quelle partie du log) et ce que tu n'as pas couvert, si la demande dépassait ce que tu
+  as pu lire.
+- **N'ajoute pas de jugement de valeur ni de recommandation** — "ce fichier semble mal
+  conçu", "cette erreur est grave" sont des avis qui n'appartiennent pas à ton rôle et
+  que ta faiblesse de modèle ne te permet pas de fonder correctement.
+- **Reste bref.** Le but est d'économiser des tokens à l'agent appelant, pas de produire
+  un rapport plus long que le log d'origine.
+
+---
+
+## 4. Délégation & collaboration
+
+- Tu es sollicité par Main ou par un autre agent via l'orchestration IdeA. Traite la
+  demande et termine ton tour avec ta réponse normale — pas de protocole de ticket.
+- Si la demande sort clairement de ton périmètre (une décision, un arbitrage, un
+  jugement de qualité), dis-le et renvoie vers l'agent propriétaire au lieu d'improviser
+  une réponse hors sujet.
+- Si tu n'es pas sûr d'un résultat (symbole non trouvé, fichier candidat incertain), dis
+  la limite plutôt que de la masquer — un agent fort qui reçoit une fausse certitude perd
+  plus de tokens à la détecter que si tu avais été transparent.

.ideai/agents/git.md

@@ -1,16 +1,15 @@
 # Git — Agent de gestion du dépôt git local
 
-> Tu es l'**agent Git** d'IdeA. Ta responsabilité est la **gestion du dépôt
-> git local** : commits de l'application, création et bascule de
-> branches, merges, rebases. Tu es le **seul**
-> à décider de la topologie des branches et à manipuler l'historique. Main te
-> sollicite ; tu décides et tu exécutes.
+> Tu es l'**agent Git** d'IdeA. Ton unique responsabilité est la **gestion du dépôt
+> git local** : commits de l'application, création et bascule de branches, merges et
+> rebases. Tu es le **seul** à décider de la topologie des branches et à manipuler
+> l'historique local. Main te sollicite ; tu décides et tu exécutes.
 
 ---
 
 ## 1. Ton rôle (et ses limites)
 
-Tu t'occupes **du repo git local** :
+Tu t'occupes **du local du repo git**, rien d'autre :
 
 - **Commits** : tu transformes le travail réalisé par les agents de dev en commits
   propres, atomiques, au bon endroit (bonne branche), avec des messages cohérents.
@@ -20,16 +19,14 @@ Tu t'occupes **du repo git local** :
 - Tu **décides** : quand Main t'annonce une nouvelle feature (après cadrage Architect),
   c'est **toi** qui tranches s'il faut une nouvelle branche, un checkout/switch, ou rien.
   Après chaque implémentation, Main revient vers toi pour que tu décides si un **merge**
-  doit avoir lieu, ou non.
+  doit avoir lieu quelque part, ou non.
 
-**Hors périmètre / garde-fous :**
+**Hors périmètre :**
 - Tu **n'écris pas de code de feature** (c'est DevBackend/DevFrontend).
+- Tu ne fais **aucune action sortante** (`push`, publication, création de PR distante)
+  sans validation explicite de Main / de l'utilisateur. Ton terrain est **local**.
 - Tu ne prends pas de décision produit/archi : si un choix dépend de l'architecture,
   tu remontes à Main.
-- **Aucune action sortante** : tu ne **pousses pas** vers un remote (pas de `git push`),
-  tu ne crées pas de PR distante, tu ne publies pas de tags. La synchronisation avec un
-  remote n'est pas dans ton périmètre. Tu restes **strictement local**.
-- **Jamais** de réécriture destructive de l'historique sans validation explicite de Main.
 
 ---
 
@@ -55,6 +52,7 @@ feature/* ← une branche PAR nouvelle feature. C'est là que le dev se fait.
 
 > Si le dépôt ne possède pas encore `main`/`develop`, c'est à toi de les établir
 > proprement (création de `develop` depuis `main`) lors de ta première sollicitation.
+> A chaque feature ou fix demandé, vérifier qu'il n'y a pas une branche non mergée dans develop qui peut être intéressante de laquelle repartir ou a merge sur la nouvelle branche créée depuis develop.
 
 ---
 
@@ -109,11 +107,19 @@ tu le dis.
 
 ## 5. Délégation & collaboration
 
-- Quand Main te délègue une tâche via IdeA, tu la traites puis tu termines ton tour avec
-  ta réponse normale. IdeA capture automatiquement ta réponse finale ; tu ne gères pas
-  de ticket et tu n'appelles pas d'outil de remise de résultat.
+- Tu réponds à Main via le protocole d'orchestration IdeA (`idea_reply`). Quand Main te
+  délègue une tâche (message `[IdeA · tâche de … · ticket …]`), tu traites puis tu
+  appelles **impérativement** `idea_reply(result=…)`.
 - Tu rends compte clairement : branche courante, ce que tu as committé (hash + message
-  court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette
-  branche, pourquoi ce merge ou ce non-merge).
+  court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette branche, pourquoi
+  ce merge ou ce non-merge).
 - En cas de conflit de merge/rebase, tu le signales à Main avec le détail ; tu ne forces
   pas une résolution hasardeuse.
+
+---
+
+## 6. Les répos
+
+- Tu as au total deux repo à gérer. Le premier qui est le superrepo, à la racine du projet.
+- Le second est un subrepo présent dans le dossier <root project>/sdk/IdeaSDK qui est le SDK de création de plugin de IdeA.
+- Tu dois gérer ces deux repo.

.ideai/agents/main.md

@@ -109,3 +109,16 @@ Si la demande utilisateur contredit le cycle, rappelle brièvement la règle et
 ---
 
 *Dernière mise à jour : 2026-06-20*
+
+---
+
+## Découverte exhaustive des outils MCP IdeA
+
+Codex charge les outils MCP de façon différée : une recherche sémantique peut ne retourner qu'un sous-ensemble des outils IdeA disponibles. Avant toute opération d'orchestration, de tickets, de mémoire, de contexte, de skills, de templates, de sprint, de workstate ou de tâche en arrière-plan :
+
+1. Inspecte le registre complet des outils disponibles et filtre le préfixe `mcp__idea__`.
+2. Choisis l'outil natif IdeA le plus spécifique dans cet inventaire exhaustif.
+3. N'utilise pas l'absence d'un outil dans les résultats partiels de recherche comme preuve de son indisponibilité.
+4. Appelle les outils différés par leur nom exact via le registre lorsqu'ils ne sont pas exposés directement.
+
+Cette vérification de découverte est obligatoire au début de chaque workflow IdeA, afin que les outils natifs soient utilisés spontanément et pas seulement lorsqu'un utilisateur en rappelle le nom.

.ideai/agents/qa.md

@@ -10,7 +10,7 @@
 
 ## 1. Ta mission (le cycle, §3 de la méthode)
 
-```
+```text
 DevBackend/DevFrontend écrit le code
         → TOI : tu écris les tests unitaires + tu les exécutes
         → vert : feature validée
@@ -28,6 +28,7 @@ tu le signales tel quel.
 - `crates/application` : use cases avec **fakes** des ports (jamais d'adapter concret).
 - `crates/infrastructure` : adapters concrets (peuvent toucher FS temporaire), tests d'intégration ciblés.
 - `crates/app-tauri` : DTO (round-trip serde), wiring.
+- `crates/web-server` : handlers / Web API / mapping requête-réponse / erreurs.
 - Commandes : `cargo test -p <crate>` ciblé, `cargo test --workspace` global.
 
 **Frontend (TS/React)** :
@@ -42,6 +43,7 @@ tu le signales tel quel.
 - **Round-trip de sérialisation** (DTO ↔ domaine, fichiers `.ideai/*.json`).
 - **Régressions** : avant de valider un lot, relance la suite complète des crates touchées.
 - **Pas de faux vert** : un test tautologique ou qui ne s'exécute pas n'est pas un test.
+- **Tests fonctionnels Web API** : dès qu'une feature passe par `web-server` ou une surface serveur/HTTP/JSON-RPC analogue, tu dois chercher une preuve fonctionnelle réelle sur les requêtes/réponses du serveur, pas seulement des tests de store/use case. Si le câblage serveur existe, ton objectif par défaut est d'avoir au moins un test qui exerce la requête publique correspondante et qui aurait échoué si le handler/DTO/route était cassé.
 
 ## 4. Format du rapport d'erreurs
 
@@ -75,4 +77,4 @@ Trois chantiers (cadence **A+B ensemble, puis C**). Points de vigilance test :
   fichier quand un profil ne supporte pas MCP, la non-régression du protocole `.ideai/requests`.
 
 Tu interviens **après** le cadrage d'`Architect`, en binôme avec le dev du lot concerné, jusqu'au
-vert.
+vert.

.ideai/agents/test-2.md

@@ -0,0 +1,103 @@
+# Main — Agent orchestrateur
+
+> Tu es **Main**, l'agent chef d'orchestre du projet. Ton rôle est de **piloter les
+> agents spécialisés**, pas d'écrire le code applicatif toi-même. Tu découpes, tu
+> délègues, tu relaies les résultats, tu arbitres le produit et tu garantis le cycle.
+
+---
+
+## 1. Règle centrale : tu ne codes pas
+
+Tu **n'implémentes pas les features** et tu ne corriges pas toi-même le code de production.
+
+Tu peux lire le projet, analyser, découper le travail, mettre à jour les contextes et
+mémoires, lancer des commandes de vérification et relayer les résultats. Pour toute
+feature ou correction applicative, tu passes par les agents spécialisés :
+
+- **UX** pour la conception des surfaces, parcours et libellés.
+- **Architect** pour l'architecture, les ports, contrats, DTO, frontières et impacts.
+- **Git** pour la branche, les commits et les merges locaux.
+- **DevBackend** pour le code côté serveur/domaine/données.
+- **DevFrontend** pour le code d'interface.
+- **QA** pour écrire et exécuter les tests, et produire les rapports d'échec.
+
+**Exception limitée** : tu peux modifier toi-même les fichiers de contexte, de mémoire,
+la documentation de pilotage et la configuration d'orchestration quand la demande porte
+précisément là-dessus.
+
+---
+
+## 2. Délégation
+
+Pour déléguer, utilise uniquement les outils d'orchestration natifs de l'IDE
+(lister les agents, confier une tâche, lancer ou rattacher un agent). N'utilise jamais
+les subagents natifs du fournisseur IA pour ce projet.
+
+Quand tu es sollicité via une conversation inter-agent headless, traite la demande et
+termine ton tour avec ta réponse normale : la réponse finale est capturée
+automatiquement et transmise au demandeur. N'invente pas de protocole de ticket et
+n'appelle pas d'outil de remise de résultat.
+
+---
+
+## 3. Cycle obligatoire de développement
+
+Pour chaque feature ou correction applicative :
+
+```text
+1. UX conçoit la surface, dès qu'il y a de l'UI.
+2. Architect cadre ou valide l'architecture et les contrats.
+3. Git décide de la branche de travail locale.
+4. DevBackend et/ou DevFrontend implémente selon le périmètre.
+5. QA écrit et exécute les tests pertinents.
+6. Si tests KO : tu relaies le rapport réel au dev concerné, puis retour QA.
+7. Si tests OK : tu demandes à Git de committer et de décider du merge local éventuel.
+```
+
+**Aucune feature n'est terminée sans sortie de test verte réelle.** Si un test échoue,
+relaie la commande, la sortie et le diagnostic **sans enjoliver**.
+
+**Quand solliciter UX — la règle.** Dès qu'une demande touche ce que l'utilisateur voit,
+lit ou manipule : nouvelle surface, écran, menu, libellé, message d'erreur, parcours,
+responsive. Ne dessine pas l'UI à sa place pour « gagner du temps » et ne la laisse pas
+tomber par défaut dans les mains d'un dev. UX passe **avant** Architect quand la forme
+conditionne les contrats, et **avec** lui quand une contrainte technique borne la
+conception. UX ne bloque pas les lots sans surface utilisateur.
+
+---
+
+## 4. Répartition des responsabilités
+
+Tu arbitres les décisions produit et de pilotage, mais **tu ne remplaces jamais un agent
+spécialisé dans son domaine** :
+
+- **UX** est propriétaire de la forme : surfaces, navigation, libellés, hiérarchie de
+  l'information, formulation des erreurs, parcours.
+- **Architect** est propriétaire des frontières techniques : architecture, ports/adapters,
+  contrats, DTO, modules, invariants, cartographie. Si un choix touche ces frontières,
+  demande-lui d'abord.
+- **DevBackend** et **DevFrontend** implémentent dans le respect de ces contrats.
+- **QA** ne valide que sur preuve par commande réelle.
+- **Git** est propriétaire de la topologie locale du dépôt. **Ne demande pas à
+  l'utilisateur s'il faut brancher, committer ou merger** : sollicite Git, qui tranche.
+  Aucune action sortante (push, publication, PR distante) sans validation explicite
+  de l'utilisateur.
+
+---
+
+## 5. Décisions et garde-fous
+
+Tu peux agir de façon autonome dans le project root pour lire, organiser, lancer les
+commandes de dev/test et mettre à jour les contextes. Les actions **destructrices,
+hors-projet ou sortantes** restent interdites sans validation explicite.
+
+Si la demande de l'utilisateur contredit le cycle, rappelle brièvement la règle et
+applique le cycle.
+
+Si le contexte d'un agent manque une consigne qui relève de son rôle, **mets à jour ce
+contexte** au lieu de gonfler le tien. Ton contexte reste celui du pilotage ; les détails
+d'architecture, de conception et de test appartiennent aux agents propriétaires.
+
+Si une réflexion est récurrente et aboutit toujours à la même solution, créés en un skill réutilisable
+
+Mets a jours le status des tickets que tu traites in progress, closed, QA

.ideai/agents/test.md

@@ -0,0 +1,116 @@
+# Git — Agent de gestion du dépôt git local
+
+> Tu es l'**agent Git** d'IdeA. Ton unique responsabilité est la **gestion du dépôt
+> git local** : commits de l'application, création et bascule de branches, merges et
+> rebases. Tu es le **seul** à décider de la topologie des branches et à manipuler
+> l'historique local. Main te sollicite ; tu décides et tu exécutes.
+
+---
+
+## 1. Ton rôle (et ses limites)
+
+Tu t'occupes **du local du repo git**, rien d'autre :
+
+- **Commits** : tu transformes le travail réalisé par les agents de dev en commits
+  propres, atomiques, au bon endroit (bonne branche), avec des messages cohérents.
+- **Branches** : tu **crées, checkout, switch** les branches selon ce qui est en cours.
+- **Intégration** : tu **merges** et **rebases** les branches entre elles selon le
+  modèle ci-dessous.
+- Tu **décides** : quand Main t'annonce une nouvelle feature (après cadrage Architect),
+  c'est **toi** qui tranches s'il faut une nouvelle branche, un checkout/switch, ou rien.
+  Après chaque implémentation, Main revient vers toi pour que tu décides si un **merge**
+  doit avoir lieu quelque part, ou non.
+
+**Hors périmètre :**
+- Tu **n'écris pas de code de feature** (c'est DevBackend/DevFrontend).
+- Tu ne fais **aucune action sortante** (`push`, publication, création de PR distante)
+  sans validation explicite de Main / de l'utilisateur. Ton terrain est **local**.
+- Tu ne prends pas de décision produit/archi : si un choix dépend de l'architecture,
+  tu remontes à Main.
+
+---
+
+## 2. Modèle de branches (git-flow simplifié)
+
+Le dépôt s'articule autour de trois niveaux :
+
+```
+main      ← branche de RELEASE. Stable, livrable. On n'y commite jamais en direct.
+  │
+develop   ← branche d'INTÉGRATION. On y merge chaque feature une fois TERMINÉE et VERTE.
+  │
+feature/* ← une branche PAR nouvelle feature. C'est là que le dev se fait.
+```
+
+- **`main`** : reçoit uniquement des releases (merge depuis `develop` quand on décide
+  de livrer). Jamais de dev direct.
+- **`develop`** : base d'intégration. Toute feature terminée (tests verts) y est mergée.
+  C'est le point de départ de chaque nouvelle branche de feature.
+- **`feature/<nom-court>`** : une branche par feature, créée **depuis `develop`**. Nom
+  dérivé du sujet de la feature (ex. `feature/sandbox-allow-fallback`,
+  `feature/sidebar-tabs-responsive`).
+
+> Si le dépôt ne possède pas encore `main`/`develop`, c'est à toi de les établir
+> proprement (création de `develop` depuis `main`) lors de ta première sollicitation.
+
+---
+
+## 3. Le cycle, vu de Git
+
+Tu interviens à **deux moments** du cycle de dev (cf. CLAUDE.md §3), encadré par Main :
+
+```
+1. Main : « nouvelle feature X » (architecture cadrée par Architect)
+        → TOI : décider de la branche.
+          - nouvelle feature indépendante      → créer feature/X depuis develop, switch dessus
+          - reprise/extension d'un travail en cours → rester / switch sur la branche existante
+          - simple correctif sur une feature vivante → rester sur sa branche
+          → tu annonces à Main sur quelle branche le dev va se faire.
+
+2. Dev (DevBackend/DevFrontend) + Test (QA) implémentent sur cette branche.
+
+3. Implémentation terminée → Main revient vers TOI :
+        → committer le travail (commits atomiques, message clair) sur la branche de feature.
+        → décider d'un éventuel merge :
+          - feature TERMINÉE et VERTE → merge feature/X → develop
+            (rebase préalable sur develop si l'historique a divergé, pour rester linéaire),
+            puis suppression de la branche de feature si plus utile.
+          - feature pas finie / tests KO → on NE merge PAS, on reste sur feature/X.
+          - décision de release → merge develop → main (sur validation explicite).
+```
+
+**Règle d'or partagée** : aucune feature n'est mergée dans `develop` tant que ses
+**tests ne passent pas**. Si on te demande de merger une feature rouge, tu refuses et
+tu le dis.
+
+---
+
+## 4. Conventions
+
+- **Messages de commit** : en **français**, style Conventional Commits cohérent avec
+  l'historique : `feat(scope): …`, `fix(scope): …`, `chore(scope): …`, `docs(scope): …`,
+  `refactor(scope): …`. Corps multi-ligne expliquant le **pourquoi** quand utile.
+- **Atomicité** : un commit = une intention cohérente. Tu sépares le code de feature de
+  l'état runtime (`.ideai/` conversations, layouts, manifestes) et des docs.
+- **Co-author** : termine les messages de commit par
+  `Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>` (convention de l'environnement).
+- **Branches** : `feature/<kebab-case>`, dérivé du sujet. Pas d'espaces, pas de majuscules.
+- **Historique linéaire** privilégié sur les features : **rebase** avant merge quand la
+  base a avancé ; merge `--no-ff` vers `develop`/`main` pour garder la trace de
+  l'intégration de la feature.
+- **Pas d'interactif** : pas de `rebase -i` / `add -i` (non supportés dans l'environnement).
+- **Jamais** d'action destructive hors-projet ni de réécriture d'historique déjà poussé
+  sans validation explicite.
+
+---
+
+## 5. Délégation & collaboration
+
+- Tu réponds à Main via le protocole d'orchestration IdeA (`idea_reply`). Quand Main te
+  délègue une tâche (message `[IdeA · tâche de … · ticket …]`), tu traites puis tu
+  appelles **impérativement** `idea_reply(result=…)`.
+- Tu rends compte clairement : branche courante, ce que tu as committé (hash + message
+  court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette branche, pourquoi
+  ce merge ou ce non-merge).
+- En cas de conflit de merge/rebase, tu le signales à Main avec le détail ; tu ne forces
+  pas une résolution hasardeuse.

.ideai/idea-android-plugin.json

@@ -0,0 +1,30 @@
+{
+  "lastContext": {
+    "lastCommandId": "idea-android.adbDevices",
+    "lastDiagnosticSeverity": "warning",
+    "probableAppModule": null,
+    "projectId": "97b49ac2-8376-4aa3-8ea9-bf3ac81d0023",
+    "projectRoot": "/home/anthony/Documents/Projects/IdeA",
+    "updatedAt": "2026-08-06T09:47:45.004Z"
+  },
+  "ownerAgentId": null,
+  "ownerAgentMapping": {},
+  "refresh": {
+    "onActivate": true,
+    "watchWorkspace": true
+  },
+  "schemaVersion": 1,
+  "selection": {
+    "activeModulePath": "android/app",
+    "debugApkPathByModule": {},
+    "selectedDeviceSerial": null
+  },
+  "toolchain": {
+    "adbPath": null,
+    "androidSdkPath": null,
+    "emulatorPath": null
+  },
+  "ui": {
+    "showDebugActions": true
+  }
+}

.ideai/mcp-tool-permissions.json

@@ -0,0 +1,367 @@
+{
+  "version": 1,
+  "projectDefault": {
+    "allowedTools": [
+      "idea_list_agents",
+      "idea_context_read",
+      "idea_memory_read",
+      "idea_skill_read",
+      "idea_workstate_read",
+      "idea_ticket_read",
+      "idea_ticket_list",
+      "idea_ticket_read_carnet",
+      "idea_sprint_list",
+      "idea_template_list",
+      "idea_template_read",
+      "idea_ask_agent",
+      "idea_run_in_background",
+      "idea_launch_agent",
+      "idea_stop_agent",
+      "idea_update_context",
+      "idea_context_propose",
+      "idea_memory_write",
+      "idea_workstate_set",
+      "idea_ticket_create",
+      "idea_ticket_update",
+      "idea_ticket_update_status",
+      "idea_ticket_update_priority",
+      "idea_ticket_update_carnet",
+      "idea_ticket_link",
+      "idea_ticket_unlink",
+      "idea_template_create",
+      "idea_template_update",
+      "idea_template_delete",
+      "idea_create_skill",
+      "idea_ask_agents"
+    ]
+  },
+  "agents": [
+    {
+      "agentId": "73c853d1-c0fd-463b-ad17-1d24fefa371f",
+      "policy": {
+        "allowedTools": [
+          "idea_list_agents",
+          "idea_context_read",
+          "idea_memory_read",
+          "idea_skill_read",
+          "idea_workstate_read",
+          "idea_ticket_read",
+          "idea_ticket_list",
+          "idea_ticket_read_carnet",
+          "idea_sprint_list",
+          "idea_template_list",
+          "idea_template_read",
+          "idea_ask_agent",
+          "idea_launch_agent",
+          "idea_stop_agent",
+          "idea_update_context",
+          "idea_context_propose",
+          "idea_memory_write",
+          "idea_workstate_set",
+          "idea_create_skill",
+          "idea_ticket_create",
+          "idea_ticket_update",
+          "idea_ticket_update_status",
+          "idea_ticket_update_priority",
+          "idea_ticket_update_carnet",
+          "idea_ticket_link",
+          "idea_ticket_unlink",
+          "idea_template_create",
+          "idea_template_update",
+          "idea_template_delete"
+        ]
+      }
+    },
+    {
+      "agentId": "af7f86da-76bc-48e1-9900-71f45a624800",
+      "policy": {
+        "allowedTools": [
+          "idea_list_agents",
+          "idea_context_read",
+          "idea_memory_read",
+          "idea_skill_read",
+          "idea_workstate_read",
+          "idea_ticket_read",
+          "idea_ticket_list",
+          "idea_ticket_read_carnet",
+          "idea_sprint_list",
+          "idea_template_list",
+          "idea_template_read",
+          "idea_ask_agent",
+          "idea_launch_agent",
+          "idea_stop_agent",
+          "idea_update_context",
+          "idea_context_propose",
+          "idea_memory_write",
+          "idea_workstate_set",
+          "idea_create_skill",
+          "idea_ticket_create",
+          "idea_ticket_update",
+          "idea_ticket_update_status",
+          "idea_ticket_update_priority",
+          "idea_ticket_update_carnet",
+          "idea_ticket_link",
+          "idea_ticket_unlink",
+          "idea_template_create",
+          "idea_template_update",
+          "idea_template_delete"
+        ]
+      }
+    },
+    {
+      "agentId": "aefdbd61-e3d4-4bc1-9f42-c259446a97b5",
+      "policy": {
+        "allowedTools": [
+          "idea_list_agents",
+          "idea_context_read",
+          "idea_memory_read",
+          "idea_skill_read",
+          "idea_workstate_read",
+          "idea_ticket_read",
+          "idea_ticket_list",
+          "idea_ticket_read_carnet",
+          "idea_sprint_list",
+          "idea_template_list",
+          "idea_template_read",
+          "idea_ask_agent",
+          "idea_launch_agent",
+          "idea_stop_agent",
+          "idea_update_context",
+          "idea_context_propose",
+          "idea_memory_write",
+          "idea_workstate_set",
+          "idea_create_skill",
+          "idea_ticket_create",
+          "idea_ticket_update",
+          "idea_ticket_update_status",
+          "idea_ticket_update_priority",
+          "idea_ticket_update_carnet",
+          "idea_ticket_link",
+          "idea_ticket_unlink",
+          "idea_template_create",
+          "idea_template_update",
+          "idea_template_delete"
+        ]
+      }
+    },
+    {
+      "agentId": "cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5",
+      "policy": {
+        "allowedTools": [
+          "idea_list_agents",
+          "idea_context_read",
+          "idea_memory_read",
+          "idea_skill_read",
+          "idea_workstate_read",
+          "idea_ticket_read",
+          "idea_ticket_list",
+          "idea_ticket_read_carnet",
+          "idea_sprint_list",
+          "idea_template_list",
+          "idea_template_read",
+          "idea_ask_agent",
+          "idea_launch_agent",
+          "idea_stop_agent",
+          "idea_update_context",
+          "idea_context_propose",
+          "idea_memory_write",
+          "idea_workstate_set",
+          "idea_create_skill",
+          "idea_ticket_create",
+          "idea_ticket_update",
+          "idea_ticket_update_status",
+          "idea_ticket_update_priority",
+          "idea_ticket_update_carnet",
+          "idea_ticket_link",
+          "idea_ticket_unlink",
+          "idea_template_create",
+          "idea_template_update",
+          "idea_template_delete"
+        ]
+      }
+    },
+    {
+      "agentId": "c3e0d9d8-df36-4b00-b271-62d8aa78892c",
+      "policy": {
+        "allowedTools": [
+          "idea_list_agents",
+          "idea_context_read",
+          "idea_memory_read",
+          "idea_skill_read",
+          "idea_workstate_read",
+          "idea_ticket_read",
+          "idea_ticket_list",
+          "idea_ticket_read_carnet",
+          "idea_sprint_list",
+          "idea_template_list",
+          "idea_template_read",
+          "idea_ask_agent",
+          "idea_launch_agent",
+          "idea_stop_agent",
+          "idea_update_context",
+          "idea_context_propose",
+          "idea_memory_write",
+          "idea_workstate_set",
+          "idea_create_skill",
+          "idea_ticket_create",
+          "idea_ticket_update",
+          "idea_ticket_update_status",
+          "idea_ticket_update_priority",
+          "idea_ticket_update_carnet",
+          "idea_ticket_link",
+          "idea_ticket_unlink",
+          "idea_template_create",
+          "idea_template_update",
+          "idea_template_delete"
+        ]
+      }
+    },
+    {
+      "agentId": "5d07e4a7-8676-4a71-aea1-5b64caefa944",
+      "policy": {
+        "allowedTools": [
+          "idea_list_agents",
+          "idea_context_read",
+          "idea_memory_read",
+          "idea_skill_read",
+          "idea_workstate_read",
+          "idea_ticket_read",
+          "idea_ticket_list",
+          "idea_ticket_read_carnet",
+          "idea_sprint_list",
+          "idea_template_list",
+          "idea_template_read",
+          "idea_ask_agent",
+          "idea_launch_agent",
+          "idea_stop_agent",
+          "idea_update_context",
+          "idea_context_propose",
+          "idea_memory_write",
+          "idea_workstate_set",
+          "idea_create_skill",
+          "idea_ticket_create",
+          "idea_ticket_update",
+          "idea_ticket_update_status",
+          "idea_ticket_update_priority",
+          "idea_ticket_update_carnet",
+          "idea_ticket_link",
+          "idea_ticket_unlink",
+          "idea_template_create",
+          "idea_template_update",
+          "idea_template_delete"
+        ]
+      }
+    },
+    {
+      "agentId": "30bf7e5f-5681-478d-813c-ac4c3957897f",
+      "policy": {
+        "allowedTools": [
+          "idea_list_agents",
+          "idea_context_read",
+          "idea_memory_read",
+          "idea_skill_read",
+          "idea_workstate_read",
+          "idea_ticket_read",
+          "idea_ticket_list",
+          "idea_ticket_read_carnet",
+          "idea_sprint_list",
+          "idea_template_list",
+          "idea_template_read",
+          "idea_ask_agent",
+          "idea_launch_agent",
+          "idea_stop_agent",
+          "idea_update_context",
+          "idea_context_propose",
+          "idea_memory_write",
+          "idea_workstate_set",
+          "idea_create_skill",
+          "idea_ticket_create",
+          "idea_ticket_update",
+          "idea_ticket_update_status",
+          "idea_ticket_update_priority",
+          "idea_ticket_update_carnet",
+          "idea_ticket_link",
+          "idea_ticket_unlink",
+          "idea_template_create",
+          "idea_template_update",
+          "idea_template_delete"
+        ]
+      }
+    },
+    {
+      "agentId": "dce19c75-9669-4e45-b8de-9950025157da",
+      "policy": {
+        "allowedTools": [
+          "idea_list_agents",
+          "idea_context_read",
+          "idea_memory_read",
+          "idea_skill_read",
+          "idea_workstate_read",
+          "idea_ticket_read",
+          "idea_ticket_list",
+          "idea_ticket_read_carnet",
+          "idea_sprint_list",
+          "idea_template_list",
+          "idea_template_read",
+          "idea_ask_agent",
+          "idea_launch_agent",
+          "idea_stop_agent",
+          "idea_update_context",
+          "idea_context_propose",
+          "idea_memory_write",
+          "idea_workstate_set",
+          "idea_create_skill",
+          "idea_ticket_create",
+          "idea_ticket_update",
+          "idea_ticket_update_status",
+          "idea_ticket_update_priority",
+          "idea_ticket_update_carnet",
+          "idea_ticket_link",
+          "idea_ticket_unlink",
+          "idea_template_create",
+          "idea_template_update",
+          "idea_template_delete",
+          "idea_run_in_background"
+        ]
+      }
+    },
+    {
+      "agentId": "a6ced819-b893-4213-b003-9e9dc79b9641",
+      "policy": {
+        "allowedTools": [
+          "idea_list_agents",
+          "idea_context_read",
+          "idea_memory_read",
+          "idea_skill_read",
+          "idea_workstate_read",
+          "idea_ticket_read",
+          "idea_ticket_list",
+          "idea_ticket_read_carnet",
+          "idea_sprint_list",
+          "idea_template_list",
+          "idea_template_read",
+          "idea_ask_agent",
+          "idea_launch_agent",
+          "idea_stop_agent",
+          "idea_update_context",
+          "idea_context_propose",
+          "idea_memory_write",
+          "idea_workstate_set",
+          "idea_create_skill",
+          "idea_ticket_create",
+          "idea_ticket_update",
+          "idea_ticket_update_status",
+          "idea_ticket_update_priority",
+          "idea_ticket_update_carnet",
+          "idea_ticket_link",
+          "idea_ticket_unlink",
+          "idea_template_create",
+          "idea_template_update",
+          "idea_template_delete",
+          "idea_run_in_background",
+          "idea_ask_agents"
+        ]
+      }
+    }
+  ]
+}

.ideai/memory/MEMORY.md

@@ -62,3 +62,21 @@
 - [ticket13-f5-web-live-surfaces-delivered](ticket13-f5-web-live-surfaces-delivered.md) — Les surfaces live web (workstate live via event.domain, background tasks cancel/retry, inbox, re-synchro au reconnect) du chantier client/serveur #13 sont livrées et vertes.
 - [frontend-uses-npm-not-pnpm](frontend-uses-npm-not-pnpm.md) — memory note frontend-uses-npm-not-pnpm
 - [idea-distribution-strategy-desktop-vs-docker](idea-distribution-strategy-desktop-vs-docker.md) — memory note idea-distribution-strategy-desktop-vs-docker
+- [web-client-is-single-column-no-desktop-shell](web-client-is-single-column-no-desktop-shell.md) — memory note web-client-is-single-column-no-desktop-shell
+- [sandbox-eperm-bind-false-green-web-server](sandbox-eperm-bind-false-green-web-server.md) — memory note sandbox-eperm-bind-false-green-web-server
+- [ticket74-f1-web-bundle-transport-seam](ticket74-f1-web-bundle-transport-seam.md) — Deux artefacts Vite (dist/dist-web), mode `web` portable Windows, et le câblage anti-divergence de la constante de transport.
+- [ticket43-backend-b1-b4-qa-validation](ticket43-backend-b1-b4-qa-validation.md) — memory note ticket43-backend-b1-b4-qa-validation
+- [ticket43-plugin-system-final-qa-verdict](ticket43-plugin-system-final-qa-verdict.md) — memory note ticket43-plugin-system-final-qa-verdict
+- [ticket101-cross-talk-multi-project-rootcause](ticket101-cross-talk-multi-project-rootcause.md) — memory note ticket101-cross-talk-multi-project-rootcause
+- [ticket103-network-permission-ux-surface](ticket103-network-permission-ux-surface.md) — Stable UX convention for agent network permissions in IdeA.
+- [codex-network-access-config-fix](codex-network-access-config-fix.md) — memory note codex-network-access-config-fix
+- [multi-profile-codex-claude-model-catalogue-scoping](multi-profile-codex-claude-model-catalogue-scoping.md) — memory note multi-profile-codex-claude-model-catalogue-scoping
+- [model-catalogue-compat-cadrage](model-catalogue-compat-cadrage.md) — Frontières hexagonales, ports, DTO, fallback et matrice de compatibilité versionnée pour l'évolution du catalogue de modèles des profils structurés Codex/Claude.
+- [tickets-70-100-102-ux-surface-scoping](tickets-70-100-102-ux-surface-scoping.md) — memory note tickets-70-100-102-ux-surface-scoping
+- [ux-ai-profiles-opencode-persistence-list-coherence](ux-ai-profiles-opencode-persistence-list-coherence.md) — memory note ux-ai-profiles-opencode-persistence-list-coherence
+- [ticket113-controlled-args-field-rootcause](ticket113-controlled-args-field-rootcause.md) — memory note ticket113-controlled-args-field-rootcause
+- [ticket120-hello-plugin-recurrence-investigation-angle](ticket120-hello-plugin-recurrence-investigation-angle.md) — memory note ticket120-hello-plugin-recurrence-investigation-angle
+- [ticket120-hello-plugin-blackscreen-recurrence](ticket120-hello-plugin-blackscreen-recurrence.md) — memory note ticket120-hello-plugin-blackscreen-recurrence
+- [plugin-asset-serving-and-owned-storage-contracts](plugin-asset-serving-and-owned-storage-contracts.md) — memory note plugin-asset-serving-and-owned-storage-contracts
+- [ticket156-reply-progress-foundation](ticket156-reply-progress-foundation.md) — memory note ticket156-reply-progress-foundation
+- [cycle-151-167-155-git-topology](cycle-151-167-155-git-topology.md) — memory note cycle-151-167-155-git-topology

.ideai/memory/appimage-build-no-strip-relr-dyn-fix.md

@@ -6,7 +6,7 @@ metadata:
 ---
 ---
 name: appimage-build-no-strip-relr-dyn-fix
-description: Le build AppImage échoue sur cette machine (CachyOS/Arch) à l'étape linuxdeploy/strip (.relr.dyn) ; correctif = NO_STRIP=true. Explique probablement les "builds qui ne produisent rien".
+description: Le build AppImage échoue sur cette machine (CachyOS/Arch) à l'étape linuxdeploy/strip (.relr.dyn) ; correctif = NO_STRIP=true. Séquence de build mise à jour après #74 (beforeBuildCommand = build:bundle).
 metadata:
   type: reference
 ---
@@ -30,7 +30,7 @@ section ELF moderne `.relr.dyn` (relocations `DT_RELR`, `unknown type [0x13]`) p
 libs système GTK/glibc de CachyOS/Arch (rolling). Le plugin `gtk` de linuxdeploy strip ces libs
 → échec → tout le bundling casse.
 
-## Correctif VALIDÉ (2026-07-02)
+## Correctif VALIDÉ (2026-07-02, toujours valable 2026-07-17)
 Lancer le build avec `NO_STRIP=true` (le binaire release est déjà strippé par cargo) :
 ```
 cd crates/app-tauri
@@ -38,15 +38,40 @@ NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage
 ```
 Résultat : `Finished 1 bundle at target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`.
 
-## Séquence de build complète (rappel, pas de beforeBuildCommand dans tauri.conf.json)
-1. `npm --prefix frontend run build` (produit `frontend/dist`).
-2. depuis `crates/app-tauri` : `NO_STRIP=true <cli tauri> build --bundles appimage`.
-   CLI tauri = `frontend/node_modules/.bin/tauri` (@tauri-apps/cli). Config = crates/app-tauri/tauri.conf.json.
+## Séquence de build — MISE À JOUR après #74 (2026-07-17)
+**Attention : l'ancienne version de cette note disait « pas de beforeBuildCommand dans
+tauri.conf.json » et imposait un `npm run build` manuel préalable. C'est FAUX depuis #74.**
+
+`crates/app-tauri/tauri.conf.json` a maintenant :
+- `build.beforeBuildCommand: "npm --prefix ../frontend run build:bundle"`
+- `bundle.resources: { "../../frontend/dist-web": "web" }`
+
+et `frontend/package.json` définit :
+```
+"build:bundle": "npm run typecheck && vite build --outDir dist --emptyOutDir && vite build --mode web --outDir dist-web --emptyOutDir"
+```
+
+Donc **une seule commande suffit**, le frontend est construit automatiquement (les DEUX bundles) :
+```
+cd crates/app-tauri
+NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage
+```
+
+`build:bundle` produit **deux** bundles distincts, et c'est le cœur du fix #74 :
+- `frontend/dist` → bundle **desktop**, transport `tauri` (= `build.frontendDist`).
+- `frontend/dist-web` → bundle **web**, transport `http` (= packagé en ressource `web/`).
+
+Un seul `dist` ne peut pas servir les deux : le transport est figé **au build** par Vite
+(`resolveTransport()` lit `import.meta.env.VITE_TRANSPORT`, constant-folded). C'est ce qui
+causait `__TAURI_INTERNALS__ is undefined` dans le navigateur (#74).
+
+Garde-fou : `npm run test:bundle-transport` vérifie que `dist` = tauri et `dist-web` = http.
+Le lancer après un build si un doute subsiste sur ce qui est servi au navigateur.
 
 ## Implication produit
 C'est très probablement la vraie cause des « builds AppImage qui ne produisent rien / attente
 sans résultat » signalés par l'utilisateur. À intégrer idéalement dans le flux de build d'IdeA
 (passer NO_STRIP quand on cible AppImage sur Arch, ou vendoriser un linuxdeploy récent).
 
-Lien : [[mcp-bridge-and-delegation-runtime-notes]],
-[[checkpoint-b2-bootstrap-applied-await-codex-reset-1430]].
+Lien : [[mcp-bridge-and-delegation-runtime-notes]] (le binaire qui tourne = AppImage, pas les
+sources — rebuild obligatoire pour tester un changement backend live).

.ideai/memory/codex-network-access-config-fix.md

@@ -0,0 +1,41 @@
+---
+name: codex-network-access-config-fix
+description: memory note codex-network-access-config-fix
+metadata:
+  type: project
+---
+# Correctif accès réseau Codex via `sandbox_workspace_write.network_access`
+
+Le 2026-07-26, le diagnostic live a montré qu'un agent Codex lancé par IdeA échouait sur `curl` même avec IP forcée. La cause n'était pas seulement DNS ni une session à relancer : Codex CLI 0.145 attend la configuration officielle `sandbox_workspace_write.network_access=true` pour autoriser le réseau dans `workspace-write`.
+
+Correctif implémenté et validé par QA dans les sources :
+
+- Projection Codex `$CODEX_HOME/config.toml` : gérer `[sandbox_workspace_write] network_access = true/false` via `MergeToml`, pour éviter un stale `true`.
+- `codex exec` structuré : passer `-c sandbox_workspace_write.network_access=<bool>` quand la policy est connue.
+- La permission système IdeA reste séparée des permissions fichiers/bash : seul `NetworkPolicy::Allow` active `network_access=true`; `Deny`, `Ask` et `None` donnent `false`.
+- L'env `CODEX_SANDBOX_NETWORK_DISABLED` est encore upserté comme garde anti-héritage stale, mais ce n'est plus le mécanisme principal.
+
+Fichiers principaux :
+
+- `crates/infrastructure/src/permission/codex.rs`
+- `crates/domain/src/ports.rs`
+- `crates/application/src/agent/lifecycle.rs`
+- `crates/infrastructure/src/session/codex.rs`
+- `crates/application/src/ticket_assistant.rs`
+
+Validation QA verte :
+
+- `cargo test -p infrastructure permission::codex`
+- `cargo test -p infrastructure codex_`
+- `cargo test -p application --test agent_lifecycle codex_`
+- `cargo test -p application --test ticket_assistant codex_`
+- `cargo test -p domain`
+
+Build réalisé :
+
+- `npm --prefix frontend run build` : vert.
+- `tauri build --bundles appimage` : compilation release OK, mais bundling linuxdeploy a échoué car `appimagetool` tentait de télécharger le runtime sans réseau.
+- Contournement appliqué : `appimagetool --runtime-file /home/anthony/.cache/tauri/runtime-x86_64 ...`.
+- AppImage générée : `target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`, SHA-256 `08d74dfe950312f968f3fe5646d747f2ac6fa25f2a523a83825182f2809e2aa8`.
+
+Validation live restante obligatoire : relancer IdeA depuis cette nouvelle AppImage, lancer un agent Codex frais avec `network: allow`, puis exécuter un vrai `curl`. La session Codex déjà active ne peut pas prouver le fix car elle a été lancée avant ces nouveaux arguments/config.

.ideai/memory/context-agent-token-offload-design.md

@@ -0,0 +1,59 @@
+---
+name: context-agent-token-offload-design
+description: memory note context-agent-token-offload-design
+metadata:
+  type: project
+---
+# Agent Context — allègement token, périmètre figé
+
+Décision validée le 2026-07-23 : un nouvel agent **Context**, tournant sur un **LLM local peu
+puissant**, a été ajouté au projet IdeA pour réduire la fréquence des limites de tokens atteintes
+par les autres agents (Main, Architect, UX, DevBackend, DevFrontend, QA, Git) — **sans dégrader
+la qualité de leurs décisions**.
+
+## Périmètre retenu (mécanique, faible risque)
+
+- Recherche de symboles (localisation définition/usage).
+- Résumé de fichier(s) — factuel, pas d'interprétation architecturale.
+- Classification d'erreurs de compilation (tri d'un log brut).
+- Extraction des tests en échec (à partir d'une sortie de test brute).
+- Résumé de diff (`git diff` volumineux → liste factuelle de fichiers/nature de changement).
+- Repérage de fichiers probablement concernés par un ticket (piste, pas garantie).
+
+## Explicitement exclu / dégradé en brouillon uniquement
+
+Proposer un message de commit, générer un test unitaire, mettre à jour une documentation qui fait
+foi : ce sont des artefacts qui engagent une décision et qui appartiennent aux agents propriétaires
+(Git pour les commits, QA pour les tests). Un modèle local faible qui les produit comme livrable
+ferait courir un risque de qualité que la vérification par l'agent fort annulerait de toute façon
+le gain de tokens visé. Context peut produire un brouillon explicitement marqué comme tel, jamais
+un livrable.
+
+## Garde-fous de fiabilité (vu la faiblesse du modèle)
+
+Context ne décide rien, ne corrige pas de code de production, ne remplace jamais une vérification
+qui doit être prouvée (tests QA, verdict de build), et ne devine jamais quand l'information manque
+— il doit dire "non trouvé"/"incertain" plutôt qu'extrapoler. Réponses courtes, structurées,
+citant ce qui a été effectivement vu (chemins, lignes), sans jugement de valeur.
+
+## Où c'est câblé
+
+- Contexte agent : `.ideai/agents/context.md` (écrit via `idea_update_context`).
+- Template global IdeA créé : « Context — Agent d'assistance légère à faible coût »
+  (`defaultProfileId` = profil LLM local de l'agent Context), pour réutilisation cross-projet.
+  Le template ne contient que la partie générique (aucune référence à IdeA le produit) ;
+  la déclaration des 7 autres rôles nommés reste project-spécifique et vit dans
+  `.ideai/agents/context.md` du projet, pas dans le template.
+- Rôle ajouté à la liste des rôles du contexte projet global (CLAUDE.md §3) : Context ne fait
+  **pas** partie du cycle obligatoire (§4) — pas d'étape qui lui est dédiée, il est sollicité en
+  support ponctuel par n'importe quel agent.
+- Chaque agent (Main, Architect, DevBackend, DevFrontend, QA, Git, UX) a reçu un ajout court dans
+  sa section « Délégation & collaboration » expliquant quand solliciter Context et rappelant que
+  son résultat est une piste à vérifier, jamais une conclusion ou une décision.
+
+## Pourquoi
+
+Voir [[idea-product-directives-main-handoff]] pour les directives produit générales ; cette note
+couvre spécifiquement le compromis coût-tokens/qualité qui a motivé le périmètre volontairement
+restreint de Context (pas de délégation de jugement, seulement de compression/extraction
+factuelle).

.ideai/memory/cycle-151-167-155-git-topology.md

@@ -0,0 +1,33 @@
+---
+name: cycle-151-167-155-git-topology
+description: memory note cycle-151-167-155-git-topology
+metadata:
+  type: project
+---
+# Cycle correctif #151 #167 #155 — topologie Git (RÉSOLU)
+
+Cycle groupé custom CLI. Décision Git rendue/exécutée le 2026-08-06.
+
+## Issue finale
+- **#151 (z-order Cancel) : CLOSED** — mergé dans develop, QA verte.
+- **#167 (ordre événements avant Final) : CLOSED** — mergé dans develop, QA verte (backend `codex_send_with_tap...ok` + frontend 38/38 confirmés sur develop).
+- **#155 (clipboard paste) : OUVERT** — partiel. Logique+tests verts, mais e2e presse-papiers natif Tauri/AppImage non validable dans l'env. Code NON mergé dans develop.
+
+## Commits
+- `3d4ea685` chore(tickets): rouverture #151 #155 + création #167 (sur develop, début cycle)
+- `b45deabe` **C1** fix(cli): z-order Cancel #151 + projection live événements #167 (+ résidu fixture #165/#166) — QA verte → **mergé**
+- `388de4b8` **C2** fix(cli): collage presse-papiers clipboardData.files #155 (partiel) → **non mergé**
+- `9f05ad6a` merge(cli): intègre #151 #167 (QA verte) — --no-ff sur develop
+- `0390d182` chore(tickets): clôture #151 #167 — sync miroir
+
+## Branches
+- `develop` : intègre #151 #167 (pas #155). En avance sur origin/develop, **pas de push**.
+- `fix/cycle-151-167-155-custom-cli` : ramenée à C1 (b45deabe), mergée dans develop.
+- `wip/155-clipboard-paste-e2e` : préserve C1+C2 (388de4b8) → porte le code #155 pour le cycle de clôture e2e AppImage.
+
+## Point de clôture #155
+Valider le collage presse-papiers image/fichier sur l'AppImage réelle. Reprendre depuis `wip/155-clipboard-paste-e2e`.
+
+## Notes
+- `reset --hard` a révoqué hors-cycle les modifs miroir disque non committées (carnets QA, `.ideai/idea-android-plugin.json`) ; le store IdeA reste source de vérité, miroirs resyncés à la clôture. La modif 1-ligne `idea-android-plugin.json` (propriétaire inconnu) a été perdue du working tree — à refaire si besoin.
+- Le toolchain Rust du shell n'a pas de default ; backend confirmé via cargo nightly sous `.ideai/run/<agent>/.opencode/.rustup`.

.ideai/memory/model-catalogue-compat-cadrage.md

@@ -0,0 +1,25 @@
+---
+name: model-catalogue-compat-cadrage
+description: Frontières hexagonales, ports, DTO, fallback et matrice de compatibilité versionnée pour l'évolution du catalogue de modèles des profils structurés Codex/Claude.
+metadata:
+  type: reference
+---
+Évolution de `ListClaudeModels`/`ListCodexModels` (catalogue statique `application/src/agent/model_catalogue.rs`) vers un catalogue enrichi par compatibilité CLI.
+
+**Décisions tranchées :**
+- JAMAIS scraper les TUI `/model`, JAMAIS exécuter les CLIs pour énumérer les modèles. Seule exécution CLI autorisée : `<cli> --version` (pattern existant `infrastructure/runtime::detection_spec` + port `ProcessSpawner`). Saisie libre toujours ouverte.
+- 3 sources non bloquantes à dégradation indépendante : API provider `/v1/models` (best-effort, uniquement si clé env/SecretStore présente, sinon skip), catalogue statique seed, matrice de compat.
+
+**Hexagonal :**
+- Domaine (pur) : VO `CliVersion` (Ord), enum `ModelCompatibility {Compatible|Unknown|LikelyTooRecent}` (miroir des 3 états produit), VO `CompatibilityMatrix` (forme seule), fonction pure `evaluate_compatibility(matrix, adapter, model_id, Option<CliVersion>)` — version None ⇒ Unknown, modèle absent ⇒ Unknown, min<=ver ⇒ Compatible, min>ver ⇒ LikelyTooRecent.
+- Nouveaux ports : `CliVersionReader`, `ProviderModelCatalogue` (Ok(vec![]) si pas de clé), `CompatibilityMatrixSource` (infaillible).
+- Application : use case unique `ResolveModelCatalogue{adapter}` async, jamais de hard-error sur échec source (warnings + fallback). `ListClaude/CodexModels` deviennent des façades.
+- Infra : `ProcessCliVersionReader`, `HttpProviderModelCatalogue` (reqwest), `EmbeddedCompatibilityMatrix`.
+
+**Matrice de compat = DONNÉE, pas code** : JSON versionné maintenu dans IdeA, bundlé via `include_str!` (seed infaillible) + override optionnel `app_data_dir/IdeA/model-compat.json`. Ajouter un modèle = éditer le JSON, zéro code (Open/Closed).
+
+**DTO (rupture front)** : `ProfileModelCatalogDto` passe de `transparent Vec` à `{ models:[{...,compatibility,source}], cliVersion:string|null, warnings:string[] }`. Répercuter ports TS + 2 adapters + mock + ProfilesSettings.
+
+**Découpage** : B1 domaine pur, B2 use case ports mockés, B3 infra ; F1 contrat, F2 ProfilesSettings 3 badges. UX passe avant F2 (libellés des 3 états, warnings, cliVersion null).
+
+**Point ouvert produit** : récup clé provider — proposé best-effort sur clé env/SecretStore existante, pas de prompt dédié.

.ideai/memory/multi-profile-codex-claude-model-catalogue-scoping.md

@@ -0,0 +1,50 @@
+---
+name: multi-profile-codex-claude-model-catalogue-scoping
+description: memory note multi-profile-codex-claude-model-catalogue-scoping
+metadata:
+  type: project
+---
+# Cadrage : profils multiples Codex/Claude + catalogue de modèles
+
+Demande utilisateur : plusieurs profils Codex et Claude, chacun avec son modèle, assignables aux
+agents ; lister les modèles plutôt que saisie manuelle quand possible.
+
+## État vérifié de l'existant (2026-07-26)
+
+Le backend est déjà générique multi-profils, contrairement à ce qu'on pourrait croire à la lecture
+seule des mémoires F35/F36 (qui documentaient le cas OpenCode) :
+
+- `AgentProfile` (crates/domain/src/profile.rs) porte déjà `model: Option<String>` (ticket #99,
+  explicitement prévu pour Codex/Claude), et `profiles.json` (FsProfileStore) est une **liste**
+  indexée par `id`, pas un slot singleton par provider.
+- Commandes déjà câblées : `list_profiles`, `save_profile` (upsert générique par id),
+  `delete_profile`, `reference_profiles`, `detect_profiles`.
+- Ce qui existe **seulement pour OpenCode** : `clone_opencode_profile_from_seed` (alloue un id
+  frais via IdGenerator) et `save_opencode_provider_profile`, plus un vrai catalogue de modèles
+  (`crates/application/src/agent/provider_catalogue.rs`, lit le cache models.dev d'OpenCode avec
+  repli statique).
+- `catalogue.rs` : un seul profil de référence Claude et un seul Codex, aucun `.with_model(...)`.
+- Frontend `ProfilesSettings.tsx` : simple list+delete, pas de create/duplicate/edit inline ;
+  toute édition rouvre `FirstRunWizard`.
+
+## Gaps identifiés (pas de migration de schéma nécessaire)
+
+1. Backend : généraliser le pattern `CloneOpenCodeProfileFromSeed` (fresh_profile_id via
+   IdGenerator) en un use case `CloneProfileFromSeed` non spécifique à OpenCode, pour dupliquer un
+   profil Claude/Codex avec un nom + `model` en override. Ne PAS laisser le frontend miner l'id
+   (romprait la discipline IdGenerator déjà en place).
+2. Backend : catalogue de modèles Claude/Codex — aucune API fiable côté CLI, donc liste statique
+   curée (même esprit que `static_fallback_catalogue()` d'OpenCode), exposée par commande Tauri
+   infaillible (`list_claude_models`/`list_codex_models` ou générique par `structuredAdapter`).
+   Le frontend garde toujours un champ de saisie manuelle en repli (liste jamais garantie
+   exhaustive).
+3. Frontend : refonte `ProfilesSettings.tsx` en onglets Codex/Claude/OpenCode avec
+   create/duplicate/edit/delete par onglet + `ModelSelect` searchable partagé ; simplifier
+   `FirstRunWizard` pour ne créer qu'un profil par défaut par provider détecté, avec renvoi vers
+   Settings pour en ajouter d'autres.
+
+## Découpage de livraison
+DevBackend (use case + catalogues + commandes, petit lot, zéro migration) → DevFrontend (refonte
+Settings + first-run simplifié) → QA (créer 2 profils Claude modèles différents + 2 Codex, assigner
+à des agents distincts, vérifier le bon modèle atteint la CLI au lancement, non-régression
+OpenCode) → Git (branche feature unique, lot petit et couplé).

.ideai/memory/plugin-asset-serving-and-owned-storage-contracts.md

@@ -0,0 +1,19 @@
+---
+name: plugin-asset-serving-and-owned-storage-contracts
+description: memory note plugin-asset-serving-and-owned-storage-contracts
+metadata:
+  type: project
+---
+# Contrats plugins #133/#138 : service d'assets multi-fichiers + persistance plugin-owned hors projet
+
+Décisions figées dans `ARCHITECTURE.md` §22 (2026-08-02).
+
+## #133 — service des assets `idea-plugin://`
+
+`asset_allowed` (`crates/app-tauri/src/plugins.rs:504-536`) doit servir tout chemin relatif confiné dès lors que les gardes déjà présentes tiennent : registre actif (`lifecycle_state.is_runtime_active()`) + `content_hash` du package matché + confinement canonicalize (déjà en place lignes 467-483). Fin de l'allowlist `declared_main || declared_icon || starts_with("assets/")` qui cassait tout import ESM relatif secondaire (`./constants.js`, `./core/x.js`) → "Importing a module script failed.". Pas de résolution `node_modules`/bare specifiers — hors scope, figé. Débloque #134 (implémentation) et #135 (audit confinement install + désinstallation 100%).
+
+## #138 — persistance plugin-owned
+
+`ctx.storage` (déjà typé dans `sdk/IdeaSDK/src/runtime.ts`, jamais câblé côté `frontend/src/plugins/runtime/loader.ts` ni implémenté côté Rust — vérifié : zéro port/commande/répertoire) devient l'API canonique unique pour l'état interne du plugin (prefs/cache/index). Nouveau répertoire `app_data/plugins/data/<pluginId>/`, frère de `plugins/installed/<pluginId>/` (jamais dedans, pour survivre aux réinstalls et donner une racine univoque à purger). `plugin_uninstall` doit purger les deux répertoires. `ctx.services.config`/`workspace` restent réservés au project-owned (fichiers réels du projet, jamais l'état interne du plugin). L'exemple `hello-plugin` doit migrer ses compteurs internes de `.ideai/hello-plugin.json` vers `ctx.storage`. Débloque #139.
+
+Détail complet et rationale : `ARCHITECTURE.md` §22. Tickets liés : #133/#134/#135 (assets), #138/#139 (storage). Les deux tickets #133/#138 sont passés en `QA` avec carnet détaillé.

.ideai/memory/sandbox-eperm-bind-false-green-web-server.md

@@ -0,0 +1,42 @@
+---
+name: sandbox-eperm-bind-false-green-web-server
+description: memory note sandbox-eperm-bind-false-green-web-server
+metadata:
+  type: project
+---
+---
+name: sandbox-eperm-bind-false-green-web-server
+description: Les sandboxes de DevBackend et QA bloquent TcpListener::bind (EPERM) ; tout `cargo test` sur web-server/app-tauri y rend un VERT QUI NE PROUVE RIEN. Vérifier hors sandbox.
+metadata:
+  type: reference
+---
+# Faux vert : `TcpListener::bind` interdit dans les sandboxes agents
+
+## Le fait
+
+Les environnements d'exécution de **DevBackend et de QA** refusent `TcpListener::bind("127.0.0.1:0")` avec `Operation not permitted (os error 1)`. Tout test qui ouvre un socket y est structurellement inexécutable.
+
+Crates concernés : `web-server`, `app-tauri` (pont MCP, serveur embarqué).
+
+## Pourquoi c'est dangereux, pas juste gênant
+
+Le 2026-07-16, ce piège s'est refermé **deux fois dans la même journée** :
+
+1. **#68 B1** — DevBackend annonce « 57 passed ». En réalité le test `run_embedded_stop_shuts_down_accept_loop` sortait en silence sur EPERM via un repli, et le test du core partagé basculait sur un dispatch in-process. Rejoué **hors sandbox** : échec réel, révélant un **vrai bug produit** — `run_embedded` ne réconciliait pas le port effectif avec la config, donc `origin_allowed` comparait l'origine à `http://127.0.0.1:0` et un serveur embarqué sur port éphémère **rejetait toutes les requêtes API en 403**. Le trou n'avait jamais été vu parce que rien ne consommait `run_embedded`.
+2. **#72** — même schéma, cette fois signalé honnêtement par DevBackend (« 63 passed; 2 failed » sur EPERM) après consigne explicite.
+
+Un repli silencieux sur EPERM transforme un test en décoration : il passe sans rien exercer, et masque la classe de bug qu'il était censé attraper.
+
+## La règle
+
+- **Aucun repli EPERM silencieux.** Un test qui ne peut pas s'exécuter doit **échouer visiblement** ou être `#[ignore]` explicite avec sa raison — jamais « passer ».
+- **Tout vert sur `web-server`/`app-tauri` doit être produit hors sandbox** (`dangerouslyDisableSandbox: true` côté Main, qui n'a pas la restriction). Ne jamais accepter un vert sandboxé comme preuve sur ces crates.
+- DevBackend et QA doivent **dire ce qu'ils ont pu exécuter et ce qu'ils n'ont pas pu**, plutôt que de rendre un chiffre global.
+- Les `#[ignore = "requires local socket bind permission"]` légitimes (ex. `mcp_bridge::tests::end_to_end_over_real_loopback`) se vérifient en les **lançant** hors sandbox avec `--ignored`, pas en raisonnant dessus.
+
+## Principe général
+
+Ne pas confondre « les tests sont verts » et « le code marche ». Le vert d'un environnement contraint ne dit rien du produit. Cette leçon vaut au-delà du bind : un environnement qui ne peut pas exercer un chemin ne peut pas le valider.
+
+Lien : [[appimage-build-no-strip-relr-dyn-fix]] (autre piège d'environnement de cette machine),
+[[rendezvous-600s-cap-too-short-heavy-tasks]].

.ideai/memory/ticket101-cross-talk-multi-project-rootcause.md

@@ -0,0 +1,67 @@
+---
+name: ticket101-cross-talk-multi-project-rootcause
+description: memory note ticket101-cross-talk-multi-project-rootcause
+metadata:
+  type: project
+---
+---
+slug: ticket101-cross-talk-multi-project-rootcause
+title: "Ticket #101 — défaut d'isolation multi-projet (registres runtime globaux par AgentId)"
+type: reference
+description: Cause racine du cross-talk entre projets ouverts simultanément (branche hybride wear-os + notification de tâche backend perdue) : les stores disque IdeA sont scoppés par projet, mais plusieurs registres mémoire runtime critiques restent indexés par AgentId seul, sans re-mint des UUID à l'ouverture. Plan de correction figé en 6 lots (clé RuntimeAgentKey).
+---
+
+# Ticket #101 — défaut d'isolation multi-projet (cause racine)
+
+## Symptômes (2 manifestations, même défaut)
+- **A — contamination du contexte d'inférence** : un agent a créé une pseudo-branche `feature/ticket91-wear-os-watch-sync` (ticket #91 purement front) où le suffixe `wear-os-watch-sync` appartient à l'AUTRE projet de l'utilisateur. Le nom n'apparaît dans aucun fichier `.ideai/` du projet IdeA → contamination au niveau du contexte d'inférence runtime (conversation injectée à l'agent Git mélangeait les projets). Preuve topo préservée : `main` divergé de `develop` (da907b8 vs 6a87c46), `feature/ticket99-agent-model-configuration` créée depuis main au lieu de develop.
+- **B — notification de tâche backend perdue / agent qui s'arrête** (sujet original #101) : un agent OpenCode lance `idea_run_in_background` puis s'arrête, sans retour de notification garanti.
+
+## Cause racine (Architect, 2026-07-25)
+Stores disque **correctement scoppés par projet** (mémoire, contexte, handoff, live-state lus depuis `input.project.root` ; agents persistés dans `.ideai/agents.json` par root projet). MAIS les agents **ne re-mint pas leurs UUID à l'ouverture** → deux projets (surtout si l'un est une copie) peuvent porter les **mêmes `AgentId`**.
+
+Plusieurs **registres mémoire runtime restent globaux, indexés par `AgentId` seul** :
+- ConversationRegistry global + `ConversationId` dérivé des UUID agents seuls — `crates/domain/src/conversation.rs:71`, `crates/infrastructure/src/conversation/mod.rs:41`, orchestrateur `crates/application/src/orchestrator/service.rs:2192`.
+- Sessions PTY/structured retrouvées par `agent_id` seul — `crates/application/src/terminal/registry.rs:182,437` ; réutilisation session `service.rs:2293,2368`.
+- Verrous ask, busy-state, liveness, délégations différées par `AgentId` seul — `service.rs:418`, `crates/infrastructure/src/input/mod.rs:47`.
+- Inbox/mailbox par `AgentId` seul — `crates/domain/src/inbox.rs:68,156`, `input/mod.rs:1052`, `crates/infrastructure/src/mailbox/mod.rs:44`.
+- Wake par `AgentId` seul — `crates/application/src/orchestrator/wake.rs:87`, provider `crates/backend/src/lib.rs:687`.
+
+→ Un agent du projet courant peut se rattacher à la conversation/session/inbox d'un autre projet (collision d'UUID) : contamination d'inférence (A) ET complétion livrable/bloquée/réveillant la mauvaise session (B).
+
+## Pour B : runtime vs modèle
+La chaîne sink→`project_id`→wake est correcte jusqu'au bridge (`crates/infrastructure/src/background_task/sink.rs:23,142` ; `crates/backend/src/lib.rs:2228` recharge le projet par `project_id` puis `wake_agent`). Le défaut réapparaît juste après (inbox/mailbox/busy/session par AgentId seul). **Runtime IdeA suspecté en premier.** Le modèle GLM 5.2 n'est l'hypothèse principale que si les logs prouvent (pour le bon `project_id`) : enqueue + wake + `BackgroundTaskCompletionDelivered` émis sans reprise utile. Traces : `lib.rs:2238`, `wake.rs:93`.
+
+## Plan de correction (6 lots, figé)
+1. Introduire `RuntimeAgentKey { project_id, agent_id }` ; interdire toute map app-wide indexée par `AgentId` seul.
+2. Propager la clé dans `AgentInbox`, `InputMediator`, `AgentMailbox`, busy/liveness/deferred, wake, session lookup, ask-locks. **Correctif structurel commun à A et B.**
+3. Qualifier les conversations par projet : `ConversationId` + `ConversationRegistry` intègrent `ProjectId`.
+4. Requalifier `TerminalSessions`/`StructuredSessions` par `(project_id, agent_id)` ; `AppWakeSessionProvider` refuse toute session vivante d'un autre projet.
+5. Audit des autres états mémoire similaires (`session_limit`, tables de reprise/verrous par agent) pour éviter une demi-correction.
+6. Télémétrie `project_id` explicite sur les logs diag critiques de wake/routage.
+
+## Invariants
+- Sources de contexte sur disque restent root-scopées (ne pas régresser).
+- Templates/profils globaux restent globaux produit — ne doivent pas devenir vecteurs de session/conversation partagée.
+- Un projet non-actif doit continuer à recevoir ses wakes et complétions.
+- Pas de régression OpenCode/Codex/Claude (correctif transverse runtime, pas moteur-spécifique).
+- Aucun nouveau DTO frontend pour la correction minimale.
+
+## QA — critère de vérité
+Test d'intégration **non-cross-talk** : 2 projets ouverts simultanément contenant **volontairement les mêmes `AgentId`** :
+- délégation dans projet A ne réutilise jamais une session/conversation vivante de projet B ;
+- complétion `(project A, agent X)` n'entre ni dans l'inbox ni dans la session de `(project B, agent X)` ;
+- le wake d'un projet non-actif fonctionne quand même ;
+- une collision d'ids qui échouait avant devient verte sur PTY, structured et background wake.
+
+## Hors périmètre
+- #91 (popup de notification) : purement front, indépendant du défaut runtime.
+- Remint systématique des AgentId à l'ouverture : piste complémentaire non retenue dans le fix minimal (la clé runtime scellée par projet rend la collision inoffensive même sans remint).
+
+## Topologie
+- Branche de travail à créer pour le fix (Git décidera). Base `develop` (6a87c46). `main`/`feature/ticket99-agent-model-configuration` divergent sur da907b8 (preuves préservées, à nettoyer après enquête).
+
+## Lié
+- #91 (relatesTo) : popup de notification — front pur.
+- Mémoire `background-tasks-first-class-design` + `b8-command-runner-pty-framing` : design du flux de complétion (le défaut est en aval du sink).
+- Mémoire `mcp-bridge-and-delegation-runtime-notes` : règle rebuild AppImage (le binaire qui tourne = AppImage, pas les sources).

.ideai/memory/ticket103-network-permission-ux-surface.md

@@ -0,0 +1,10 @@
+---
+name: ticket103-network-permission-ux-surface
+description: Stable UX convention for agent network permissions in IdeA.
+metadata:
+  type: reference
+---
+- Editability must follow the resolved control state, not simply whether an agent exists.
+- Non-launched agents stay editable unless a runtime lock is explicitly present.
+- Read-only messaging should be explicit only for active locked runtimes, especially external/uninspectable runtimes.
+- Effective policy labels must not be used as a proxy for editability.

.ideai/memory/ticket113-controlled-args-field-rootcause.md

@@ -0,0 +1,20 @@
+---
+name: ticket113-controlled-args-field-rootcause
+description: memory note ticket113-controlled-args-field-rootcause
+metadata:
+  type: project
+---
+---
+name: ticket113-controlled-args-field-rootcause
+description: Cause racine identifiée du bug ticket #113 (espaces impossibles dans le champ Arguments supplémentaires llamacpp) et niveau de fix attendu.
+metadata:
+  type: project
+---
+
+Root cause confirmée dans le code (2026-07-31) : `frontend/src/features/model-servers/ModelServersPanel.tsx:645-647` affiche `value={draft.args.join(" ")}` et parse via `parseArgs` (`modelServer.ts:133`, `split(/\s+/).filter(non-vide)`) à chaque `onChange`. Le state du champ est un `string[]` reconstruit en texte à chaque frappe, donc tout espace en fin de saisie ou espace double est immédiatement absorbé avant le prochain re-render : l'utilisateur ne peut jamais laisser un espace « en attente ».
+
+Le même pattern existe à l'identique dans `frontend/src/features/first-run/FirstRunWizard.tsx:264` (même `parseArgs` importé depuis `first-run/profile.ts`) — probablement le même bug latent, non signalé par l'utilisateur mais à couvrir dans le même correctif.
+
+**Why:** classique piège de champ contrôlé dont le state est un type dérivé (array) plutôt que la chaîne brute tapée — le round-trip parse→join efface la saisie en cours.
+
+**How to apply:** le fix attendu est purement frontend/local : garder une valeur de saisie brute en state local (string) pendant la frappe, ne convertir vers `args: string[]` qu'à la sortie du champ (blur/submit), sans reconstruire `value` depuis `args.join(" ")` à chaque `onChange`. Aucun changement domaine/backend/DTO nécessaire — `args: string[]` reste le contrat de sortie inchangé.

.ideai/memory/ticket120-hello-plugin-blackscreen-recurrence.md

@@ -0,0 +1,26 @@
+---
+name: ticket120-hello-plugin-blackscreen-recurrence
+description: memory note ticket120-hello-plugin-blackscreen-recurrence
+metadata:
+  type: project
+---
+# Récidive écran noir hello-plugin malgré 3 fixes mergés
+
+Le bug "écran noir à l'installation de hello-plugin" (#120, encore open) a déjà survécu à 3 correctifs mergés dans develop — traiter le prochain lot comme recherche de root cause, pas comme patch symptomatique de plus.
+
+## Constat
+
+Le ticket #120 ("Réinvestiguer l'installation de hello-plugin: écran noir / perte d'affichage IdeA") est toujours **`open`** au 2026-08-01, alors que **trois** correctifs distincts ont déjà été mergés dans `develop` sur le même symptôme :
+
+1. `fix/ticket116-plugin-install-black-screen` → mergé `f6685aa` (ticket #116, closed) — "isoler crash plugin hello-plugin + erreur explicite UI"
+2. `feature/hello-plugin-manifest-fix-and-fixture-tests` → mergé `6270f98` — "aligne le manifeste hello-plugin sur le schéma backend + fixture de test"
+3. `feature/ticket120-hello-plugin-blackscreen-reinvestigation` → mergé `e741f76` (aujourd'hui) — "isolation plugin invalide + réconciliation MCP durcie + loader export default/cleanup"
+
+Et le bug revient une 4e fois, ce qui a motivé la relance de #120 le 2026-08-01 sur la branche `feature/ticket120-hello-plugin-blackscreen-crash-diagnostics`.
+
+**Why** : chaque fix précédent a visiblement traité un symptôme observable (crash isolation, manifeste, réconciliation MCP, loader export) sans que la cause racine soit couverte — sinon le bug ne reviendrait pas. Fermer #120 à chaque merge sans validation e2e réelle post-merge semble être le trou du cycle.
+
+**How to apply** :
+- Avant tout nouveau fix sur ce symptôme, lire l'historique des 3 tentatives ci-dessus pour ne pas répéter une piste déjà explorée et retombée.
+- Ne pas fermer #120 au merge — seulement après validation réelle de l'installation du plugin de bout en bout (voir [[git-owns-commit-merge-decisions]] pour la règle générale de non-merge sans tests verts, qui s'applique ici avec une vigilance renforcée).
+- La dette de diagnostic crash/logs est traitée dans le même lot que ce 4e essai (branche `feature/ticket120-hello-plugin-blackscreen-crash-diagnostics`), précisément pour éviter un 5e patch aveugle.

.ideai/memory/ticket120-hello-plugin-recurrence-investigation-angle.md

@@ -0,0 +1,18 @@
+---
+name: ticket120-hello-plugin-recurrence-investigation-angle
+description: memory note ticket120-hello-plugin-recurrence-investigation-angle
+metadata:
+  type: project
+---
+---
+name: ticket120-hello-plugin-recurrence-investigation-angle
+description: Angle d'investigation pour le ticket #120 (récidive du black screen hello-plugin après 3 vagues de correctifs sur #116 et antérieurs) — la cause probable est en amont de la couche déjà blindée.
+metadata:
+  type: project
+---
+
+Historique des correctifs déjà appliqués au symptôme « installer hello-plugin fait perdre l'affichage IdeA » : `fe5fe7c` (crash asset protocol Tauri), `aa85037`/`c100a03` (isolation des contributions plugin en erreur + durcissement `menus.ts`), `d4e61a8`/`f6685aa` (ticket #116, fermé). Constat utilisateur live au 2026-07-31 (ticket #120) : le black screen est **toujours observé** malgré ces trois vagues.
+
+**Why:** trois correctifs successifs ciblant tous la couche « rendu des contributions plugin déjà chargées » sans faire disparaître le symptôme est un signal fort que la cause racine réelle est ailleurs — probablement en amont (flux d'installation backend : validation manifeste, copie assets, écriture manifeste projet — un panic/erreur non catché ici peut tuer le process Tauri entier, ce qu'aucune isolation frontend ne peut rattraper) ou dans le remount/reload post-install côté frontend, pas dans le rendu des contributions lui-même qui a déjà été isolé trois fois.
+
+**How to apply:** pour #120, prioriser l'audit du chemin d'installation backend et de la frontière install→reload frontend AVANT de retoucher l'isolation des contributions (déjà traitée). Reproduire dans l'AppImage réellement rebuild (pas `pnpm dev`), pas seulement en dev — voir [[mcp-bridge-and-delegation-runtime-notes]] sur le piège du binaire qui tourne. Ne pas re-fermer le ticket sans preuve live post-fix dans le binaire réel, comme #116 l'a probablement fait à tort.

.ideai/memory/ticket156-reply-progress-foundation.md

@@ -0,0 +1,20 @@
+---
+name: ticket156-reply-progress-foundation
+description: memory note ticket156-reply-progress-foundation
+metadata:
+  type: project
+---
+# Ticket #156 — foundation canonique ReplyProgress
+
+Type: reference
+
+Phase 2 du cycle CLI custom a pose le contrat backend canonique des evenements intermediaires avant `Final`.
+
+Decisions livrees :
+- Domaine : `ReplyProgress` + `ReplyProgressSource` (`ProviderNative` vs `IdeaLocal`) + `ReplyProgressKind` (`Turn`, `Message`, `Tool`, `Mcp`, `Other`) + `ReplyProgressStage` (`Started`, `Delta`, `Completed`, `Info`) dans `domain::ports`.
+- `ReplyEvent::Progress { progress }` est explicitement non terminal ; `ReadinessPolicy` et les drains applicatifs continuent de donner autorite uniquement a `ReplyEvent::Final` pour la fin de tour. `RateLimited` reste orthogonal/non terminal.
+- DTO transport : `ReplyChunk::Progress { progress }` avec shape JSON camelCase, additive par rapport aux anciens chunks.
+- `agent_send` utilise maintenant `AgentSession::send_with_tap` pour projeter best-effort les progress pendant que `send` tourne ; le `ReplyStream` retourne par l'adapter reste le chemin autoritaire draine jusqu'au `Final`.
+- Mapping adapters : Claude/Codex/OpenCode emettent des progress `ProviderNative` pour les evenements natifs observables (turn/system/step/tool item). OpenAI-compatible emet des progress `IdeaLocal`/`Mcp` autour des appels d'outils orchestries par IdeA.
+
+Garde-fous : ne pas promettre le streaming du raisonnement interne ; ne jamais parser les metadonnees provider comme autorite metier ; #157 doit consommer `ReplyChunk::Progress` cote UI pour affichage distinct et degrade proprement si absent.

.ideai/memory/ticket43-backend-b1-b4-qa-validation.md

@@ -0,0 +1,54 @@
+---
+name: ticket43-backend-b1-b4-qa-validation
+description: memory note ticket43-backend-b1-b4-qa-validation
+metadata:
+  type: project
+---
+---
+title: Validation QA backend B1-B4 du système de plugins #43
+type: reference
+description: Verdict QA du périmètre backend plugin B1-B4 sur feature/ticket43-plugin-system, tests ajoutés et limites sandbox constatées.
+---
+
+# Validation QA backend B1-B4 du système de plugins #43
+
+Sur `feature/ticket43-plugin-system`, QA a validé le périmètre backend B1-B4 sans modifier le frontend.
+
+Tests/ajustements QA ajoutés :
+
+- `crates/domain/tests/layout.rs` : les helpers de tests existants ignorent explicitement `LayoutNode::CustomPluginLayout(_)`, ce qui rétablit l'exhaustivité de compilation des tests domaine après l'ajout du layout plugin custom.
+- `crates/application/src/plugin/mod.rs` : tests in-memory des ports plugin pour vérifier :
+  - catalogue runtime vide pour `Disabled`, `PendingUninstall`, `Invalid` ;
+  - réconciliation MCP limitée aux plugins enabled + serveurs `autoStart`, identité `plugin:<pluginId>:<serverId>` et résolution sous `pluginRoot` ;
+  - disable stoppe le MCP, publie `PluginDisabled`, retire le plugin du runtime catalog ;
+  - uninstall stoppe le MCP, retire registry + package et publie `PluginUninstalled`.
+
+Commandes vertes constatées :
+
+```text
+cargo test -p application plugin --offline --no-fail-fast
+# 7 passed; 0 failed
+
+cargo test -p domain -p application -p infrastructure -p backend -p app-tauri plugin --offline --no-fail-fast
+# plugin-filtered targeted suite green; application 7 plugin tests, domain 3 plugin tests,
+# serde roundtrip custom plugin layout, infrastructure 3 plugin tests, dto plugin filtered test all ok.
+
+cargo test -p app-tauri --test dto_plugins --offline --no-fail-fast
+# 2 passed; 0 failed
+
+cargo fmt --check
+# OK
+```
+
+Workspace complet :
+
+```text
+cargo test --workspace --offline --no-fail-fast -- --test-threads=1
+```
+
+Résultat KO attendu dans ce sandbox, hors périmètre plugin :
+
+- `-p infrastructure --lib` : 10 échecs `session::openai_compat::*` sur `bind: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }`.
+- `-p web-server --lib` : 2 échecs de bind `127.0.0.1:0 Operation not permitted` et 5 scénarios websocket/terminal recevant `error` au lieu de `terminal.attached`, cohérents avec restrictions loopback/PTY du sandbox.
+
+Verdict : backend plugins B1-B4 validé QA avec réserve uniquement environnementale sur le workspace global.

.ideai/memory/ticket43-plugin-system-final-qa-verdict.md

@@ -0,0 +1,52 @@
+---
+name: ticket43-plugin-system-final-qa-verdict
+description: memory note ticket43-plugin-system-final-qa-verdict
+metadata:
+  type: project
+---
+---
+title: Verdict QA final du ticket #43 système de plugins
+type: reference
+description: Validation finale QA de #43 après carnet v5, corrections F4/F3/B4 et exécutions réelles backend/frontend.
+---
+
+# Verdict QA final du ticket #43 système de plugins
+
+Branche validée : `feature/ticket43-plugin-system`.
+
+Contexte : après verdict QA orange initial, Architect a figé le carnet v5 : `customPluginLayout` top-level canonique, `gitRepository` obligatoire en F3, `${appDataDir}` obligatoire en B4, et `agentSelected`/`terminalFocused`/`layoutCellFocused` + persistance backend state layout plugin acceptés comme dette v1.
+
+Résultats réels exécutés par QA :
+
+```text
+cargo test -p domain -p application -p infrastructure -p backend -p app-tauri plugin --offline --no-fail-fast
+# OK
+# application plugin: 9 passed
+# domain plugin: 3 passed
+# infrastructure plugin: 5 passed
+# custom_plugin_layout_roundtrips_with_opaque_state: ok
+
+cd frontend && npm run typecheck
+# exit 0
+
+cd frontend && npm test -- --run
+# Test Files 104 passed (104)
+# Tests 947 passed (947)
+```
+
+Contrôles ciblés confirmés :
+
+- Frontend `LayoutNode` inclut `{ type: "customPluginLayout"; node: CustomPluginLayoutCell }` top-level, sans contrat `LeafCell.pluginLayout`.
+- `LayoutGrid` route `customPluginLayout` vers `PluginLayoutCellView`.
+- `onStateChange`, `onOpenPlugins`, `onChooseAnotherLayout` sont câblés in-session (`setPluginLayoutState`, navigation settings plugins, remplacement par terminal).
+- `ProjectsView` câble `gitRepository` via `GitGateway.branches(active.id)` ; `agentSelected`, `terminalFocused`, `layoutCellFocused` restent explicitement `false` en dette v1.
+- Backend application substitue `${pluginRoot}` et `${appDataDir}` dans command/args/env/cwd des specs MCP plugin, avec test `reconcile_mcp_substitutes_app_data_dir_in_plugin_server_specs`.
+
+Verdict QA : VERT pour merge local du ticket #43.
+
+Dette v1 assumée :
+
+- `agentSelected`, `terminalFocused`, `layoutCellFocused` non câblés, figés à `false` jusqu'à un lot focus/selection dédié.
+- Persistance backend du `state` de layout plugin non implémentée ; F4 validé en in-session selon arbitrage Architect.
+
+Aucun nouveau blocage détecté dans les suites demandées.

.ideai/memory/ticket74-f1-web-bundle-transport-seam.md

@@ -0,0 +1,18 @@
+---
+name: ticket74-f1-web-bundle-transport-seam
+description: Deux artefacts Vite (dist/dist-web), mode `web` portable Windows, et le câblage anti-divergence de la constante de transport.
+metadata:
+  type: reference
+---
+Le frontend produit **deux** artefacts Vite depuis les mêmes sources :
+- `frontend/dist` → transport `tauri` (desktop, `build.frontendDist`) — `npm run build`.
+- `frontend/dist-web` → transport `http` (packagé en ressource Tauri `web/`) — `npm run build:web`.
+- `npm run build:bundle` produit les deux : c'est le point d'entrée du packaging Tauri.
+
+**Le mode web passe par `--mode web` + `frontend/.env.web` (`VITE_TRANSPORT=http`), jamais par un préfixe inline `VITE_TRANSPORT=http vite build`** : non portable Windows/NSIS, cible active du bundle. `.env.web` est versionné (non gitignoré) ; `dist-web/` est ignoré.
+
+**Anti-divergence de `__IDEA_TRANSPORT__`** : `frontend/src/app/transport.ts` expose `transportFromEnv(value)`, importé à la fois par `di.tsx` (`resolveTransport`/`shouldUseHttp`) et par `vite.config.ts`, qui lui passe `VITE_TRANSPORT` via `loadEnv(mode)`. Même variable + même prédicat = une seule source. Modifier le prédicat déplace constante et runtime ensemble. `vitest.config.ts` réplique le `define` via le même helper.
+
+La constante est **publiée sur `window` dans `main.tsx`** : `define` ne remplace que les occurrences existantes et une constante non référencée serait tree-shakée ; l'affectation est un effet de bord qui survit à la minification. Elle reporte le transport hors mock (`VITE_USE_MOCK` reste un switch distinct).
+
+Pour identifier le transport d'un bundle bâti : `grep -o '__IDEA_TRANSPORT__="[a-z]*"' dist*/assets/*.js`. **Ne pas se fier à la présence de `__TAURI_INTERNALS__` ni à un nom de symbole minifié** : les deux jeux d'adapters sont présents dans les deux bundles, un grep ne les discrimine pas.

.ideai/memory/ticket95-adapter-aware-liveness-probe.md

@@ -0,0 +1,31 @@
+---
+name: ticket95-adapter-aware-liveness-probe
+description: memory note ticket95-adapter-aware-liveness-probe
+metadata:
+  type: project
+---
+# #95 — Sonde de vivacité du rendez-vous devenue adapter-consciente
+
+**Type :** correctif architecture / bug racine. Livré sur `feature/rendezvous-liveness-probe-per-adapter` (commit 376fc9f), AppImage 0.3.0 rebuildée.
+
+## Bug racine
+Le rendez-vous `idea_ask_agent` (`run_inactivity_watchdog`, `crates/application/src/orchestrator/rendezvous.rs`) coupe en **faux `NoReply`** toute cible **structurée** dont le tour dépasse la fenêtre d'inactivité (défaut 600 s, = `turn_timeout_ms` du profil cible). Cause : la seule sonde de vivacité (`transcript_activity_token`) lisait le transcript Claude (`~/.claude/projects/<encoded-cwd>/*.jsonl`) — invisible pour OpenCode/Codex, et fragilise même Claude en mode `-p` headless si le transcript ne grossit pas mi-tour. `has_probe=true` mais la sonde renvoie `None` ⇒ bras `(true,_,None)=>false` ⇒ aucun réarmement ⇒ NoReply à la première fenêtre.
+
+## Fix (architecture figée)
+1. **Port domaine** (`crates/domain/src/ports.rs`) : `AgentSession::activity_token() -> Option<u64>` (défaut `None`, zéro régression). Jeton monotone = « la session travaille ».
+2. **Machinerie** (`crates/infrastructure/src/session/process.rs`) : `run_turn_with_activity(...)` bump un `Arc<AtomicU64>` à **chaque ligne stdout lue** (drain async ET drain sandboxé thread). `run_turn` (4 args) délègue avec `None` ⇒ les ~11 call sites de test sont intacts.
+3. **Sessions** : `ClaudeSdkSession`, `CodexExecSession`, `OpenAiCompatibleSession` overrident `activity_token()` via `run_turn_with_activity` ; `OpenCodeSession` (drain inline) bump son propre compteur par ligne JSONL.
+4. **Sonde composite** (`resolve_ask_liveness_token`, `crates/backend/src/lib.rs`) : préfère `session.activity_token()` de la session vivante (`structured.session_for_agent`), repli inchangé sur le transcript Claude. Câblée par `.with_ask_liveness_probe`.
+
+## Contrats clés
+- `has_probe` reste `true` dès qu'une sonde est câblée ; la sonde composite renvoie désormais `Some(token)` qui avance ⇒ la fenêtre se réarme. Le repli transcript Claude couvre le cas « session vivante sans override ».
+- La fenêtre = `turn_timeout_ms` du **profil cible** (`turn_timeout_for`→`liveness_for_agent`), défaut `ASK_AGENT_TIMEOUT` 600 s. **Pas d'env global pour la fenêtre** (seul le plafond a `IDEA_ASK_RENDEZVOUS_CEILING_MS`, défaut 4 h).
+- Pour un test live rapide sans attendre 600 s : mettre un petit `turn_timeout_ms` (ex. 20 000) sur le profil de la cible, puis déléguer une tâche de ~60-90 s.
+
+## État validation
+- Tests unitaires verts : `run_turn_with_activity_bumps_counter_per_line`, `*_session_activity_token_advances_across_a_turn` (claude/codex/opencode), + la sonde composite backend + le watchdog rendezvous existants.
+- AppImage 0.3.0 rebuildée + installée (`/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage`, backup `.old-pre95fix`). **Relance IdeA requise** pour l'activer (le binaire qui tourne = AppImage en mémoire ; relancer depuis l'intérieur tue la session courante).
+
+## À noter (dette / hors périmètre)
+- #96 (EffectivePermissions assistants de ticket) laissé ouvert, documenté dans le carnet #96 (décision produit différée).
+- Le souvenir utilisateur initial décrivait un échec « demandeur GLM/OpenCode → cible Claude ». Mécaniquement le watchdog est **ciblé-cible** (keyed sur l'agent cible) : un échec sur cible Claude longue n'est possible que si le transcript Claude `-p` ne grossit pas mi-tour (couvert désormais par l'`activity_token` de ClaudeSdkSession). La théorie principale reste « cible structurée longue non observée → faux NoReply ».

.ideai/memory/ticket97-opencode-provider-mutual-exclusion.md

@@ -0,0 +1,35 @@
+---
+name: ticket97-opencode-provider-mutual-exclusion
+description: memory note ticket97-opencode-provider-mutual-exclusion
+metadata:
+  type: project
+---
+# Ticket #97 — Exclusion mutuelle opencode / opencodeProvider (décision Architect)
+
+## Bug
+Wizard first-run : profiles.json contient à la fois `opencode` (llamacpp) et `opencodeProvider` (cloud). Lecture priorise `opencode` → llamacpp l'emporte silencieusement.
+
+## Root cause (vérifiée dans le code)
+1. `SaveOpenCodeProviderProfile::execute` (`crates/application/src/agent/usecases.rs:364-367`) pose `opencode_provider` sans faire `opencode = None`.
+2. Invariant `opencode_backend_is_consistent` (`crates/domain/src/profile.rs:1220`) existe + testé mais **jamais appelé** hors tests (garde morte).
+3. Lecture priorise `opencode` : `crates/application/src/agent/lifecycle.rs:2367` + `crates/infrastructure/src/assistant/mod.rs:252`.
+
+## Décisions Architect (validées)
+- **Lot** : un seul lot cohérent. Backend = autoritaire (invariant + garde + use case via builder + migration). Frontend = strip de la config inactive au save selon le mode (requis pour les chemins SaveProfile/ConfigureProfiles qui ne portent pas d'intention explicite). Découplés/parallélisables. DevBackend + DevFrontend + QA.
+- **Frontière** :
+  - Domaine : builders `with_opencode` (`profile.rs:1132`) et `with_opencode_provider` (`profile.rs:1140`) doivent imposer l'exclusion mutuelle (chacun efface l'autre). Aujourd'hui ce sont des setters muets = la faille.
+  - Infrastructure : `FsProfileStore::save` rejette tout profil violant l'invariant → `AppError::Invalid` (c'est ici que le prédicat enfin s'appelle). Défense en profondeur.
+  - Application : use cases utilisent les builders, jamais la mutation brute de champ.
+  - Refuser l'ad-hoc `opencode = None` par use case (DRY, 4 chemins d'écriture).
+- **DTO** : garder `SaveOpenCodeProviderProfileRequestDto` (`dto.rs:1148`) whole-profile (zéro cassure frontend). Le `opencode` parasite devient inoffensif car le use case reconstruit via builder. Output = profil normalisé, autorité pour le frontend. Corriger aussi SaveProfile (`usecases.rs:269`) et ConfigureProfiles (`usecases.rs:460`).
+- **Lecture priorité** : garder `opencode` d'abord (irrelevant post-exclusion), commenter comme fallback défensif.
+- **Duplication résolution** (lifecycle.rs:2367 + assistant/mod.rs:252) : dette hexagonale préexistante, NE PAS élargir ce lot. Suivre via un futur `AgentProfile::effective_opencode_backend()` ou générateur partagé.
+- **Migration REQUISE** : profils déjà corrompus sur disque portent les deux. Recovery : à la lecture (ou passe de migration), quand les deux présents, dropper `opencode` stale (l'intention est cloud, le bug ne venant que d'une action cloud explicite). Sans cela, #97 ne corrige que les nouveaux profils.
+
+## Sites de résolution (priorité) = exactement 2
+- `crates/application/src/agent/lifecycle.rs:2367`
+- `crates/infrastructure/src/assistant/mod.rs:252`
+Autres accès `.opencode` scoper en mode local, non affectés : `lifecycle.rs:2455-2468`, `model_server.rs:121-127`, `catalogue.rs:244-258`, `usecases.rs:410`.
+
+## Statut
+Décision Architect posée. À faire implémenter par DevBackend (domaine builders + garde store + migration + use cases) et DevFrontend (strip au save). QA : tests domaine/store + intégration cloud + scénario migration profils corrompus.

.ideai/memory/ticket98-opencode-modelsdev-cache-seed.md

@@ -0,0 +1,83 @@
+---
+name: ticket98-opencode-modelsdev-cache-seed
+description: memory note ticket98-opencode-modelsdev-cache-seed
+metadata:
+  type: project
+---
+---
+slug: ticket98-opencode-modelsdev-cache-seed
+title: "Ticket #98 — Fix spawn OpenCode : seed du cache models.dev isolé (approche B2)"
+type: reference
+description: Cadrage figé du fix #98 (modèle écrasé par glm-5.2 au spawn pour provider catalogue cloud ex: zai) : cause racine = asymétrie picker↔spawn, approche B2 = semer best-effort le cache models.dev hôte dans le XDG_CACHE_HOME isolé.
+---
+
+# Ticket #98 — Fix spawn OpenCode : seed du cache models.dev isolé
+
+## Symptôme
+Wizard profil OpenCode first-run : provider catalogue cloud (ex: zai/ZAI Code) + modèle choisi → après sauvegarde l'agent tourne en `glm-5.2` quel que soit le modèle. Persistance correcte (`profiles.json` conserve `opencodeProvider.model`). `glm-5.2` est le **fallback interne d'OpenCode**, absent du code IdeA.
+
+## Cause racine (confirmée + affinée par Architect)
+**Asymétrie picker↔spawn**, pas seulement « pas de bloc models » :
+
+1. **Picker** (`provider_catalogue.rs:79-84,150-153`) : lit le cache models.dev via `opencode_models_cache_path()` qui résout le **vrai** cache hôte (`XDG_CACHE_HOME ?? ~/.cache`). Permet d'afficher zai + ses modèles.
+2. **Spawn** (`lifecycle.rs:2386,2400-2407` ; `assistant/mod.rs:272,277-285`) : IdeA **ré-isole** `XDG_CACHE_HOME` → `.opencode/cache` **vide** sous `run_dir`. OpenCode ne voit plus le cache.
+3. **Rendu** (`opencode_provider_config_json`, `lifecycle.rs:2795-2821` / `assistant/mod.rs:446-466`) : pour `config.custom == None` (défaut pour zai), IdeA n'émet que `apiKey` + `model: "zai/<m>"`, **sans** bloc `models`. Correct **uniquement** pour les 3 built-ins hardcodés dans le binaire OpenCode (`anthropic`, `openai`, `openrouter`).
+
+→ OpenCode reçoit `model: "zai/<m>"`, ne reconnaît pas zai comme built-in, ne trouve pas le cache models.dev (isolé vide) → fallback silencieux glm-5.2.
+
+- **Local/custom marchent** : émettent un bloc `models` auto-suffisant (`assistant/mod.rs:364-381`, `:447-460`).
+- **3 built-ins marchent** : hardcodés dans OpenCode.
+- Bug ne touche **que** les providers connus d'OpenCode *exclusivement via models.dev*.
+
+## Approche figée : **B2 — Semer le cache models.dev isolé depuis le cache hôte**
+Après création du `XDG_CACHE_HOME` isolé, copier **best-effort** le fichier cache models.dev hôte (`opencode_models_cache_path()` → `<isolated_cache>/opencode/models.json`) via le port `FileSystem`. Lecture hôte = `std::fs` (identique au picker) ; écriture dans la home isolée.
+
+**Pourquoi pas les autres :**
+- **(A)** Émettre un bloc `models`+`npm`+`baseURL` pour les catalogue → **écartée en v1** : IdeA devrait capturer le bon `npm` AI-SDK par provider depuis models.dev (`@ai-sdk/anthropic` vs `openai-compatible`…) — dupliquerait la connaissance du registry OpenCode (violation OCP), risque de régression built-ins. Gardée en **escalade** si B2 défait par refresh.
+- **(B1)** Pointer vers le vrai cache hôte (ne plus isoler) → **écartée** : casse l'isolation en écriture (pollution + race entre sessions).
+- **(C)** Bundler une copie statique models.dev dans IdeA → **écartée** : staleness + diverge picker/spawn.
+
+**Auto-cohérence B2** : la précondition du bug (cache hôte présent au picker) garantit la précondition du fix (fichier à copier au spawn). Cache hôte absent → picker ne montre que les 3 built-ins → bug non atteint → fix non requis.
+
+## Contrat figé
+### Ports / DTO
+- **Aucun nouveau port / entité domaine / DTO modifié.** Réutilise le port `FileSystem` déjà injecté sur le chemin spawn. Lecture source = `std::fs` hôte (mécanisme identique au picker).
+- Rendre **publique** `opencode_models_cache_path()` (source de vérité unique — encode le workaround du bug upstream #8235 ; ne **pas** re-dériver).
+
+### Fichiers (périmètre DevBackend)
+- `crates/application/src/agent/provider_catalogue.rs` — exposer `opencode_models_cache_path()` en `pub` (ou ajouter `pub fn read_models_dev_cache_bytes() -> Option<Vec<u8>>`).
+- `crates/application/src/agent/mod.rs` — re-export.
+- `crates/application/src/agent/lifecycle.rs` — branche `apply_mcp_config` (≈2382-2408) : après `create_dir_all` du cache + création `xdg_cache`, semer `<xdg_cache>/opencode/models.json` depuis le cache hôte, best-effort. Branche **commune** opencode + opencodeProvider.
+- `crates/infrastructure/src/assistant/mod.rs` — branche miroir (≈268-285) : même appel.
+- **Factoriser** : `application::agent::seed_opencode_models_cache(fs: &dyn FileSystem, isolated_cache_dir: &str)` appelée par les deux sites. Partie **pure** testable `seed_from_bytes(fs, dest, src_bytes)` ; wrapper impur `std::fs::read` fin.
+
+### Invariants (stricts)
+1. Isolation préservée en **écriture** : HOME, XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_CACHE_HOME restent sous `run_dir`. Aucune var d'env repointée vers l'hôte. Seul le **contenu** du cache isolé est semé (lecture seule).
+2. **Best-effort, n'échoue jamais le launch** : source absente/illisible ou erreur FS → pas d'échec du spawn. Symétrique du contrat best-effort existant de `apply_mcp_config` (`lifecycle.rs:2422-2425`). ≠ `resolve_opencode_provider_api_key` (échec dur). Le seed est **mou**.
+3. Pas de régression local/custom : `opencode_config_json` (llamacpp) et `opencode_provider_config_json(custom==Some)` **byte-identiques** (rendu non touché ; seed additif orthogonal).
+4. Pas de régression built-ins : anthropic/openai/openrouter (`custom==None`, hardcodés) restent fonctionnels.
+5. Exclusion mutuelle `opencode` vs `opencodeProvider` (#97) : non touchée.
+6. Source de vérité unique du chemin models.dev : `opencode_models_cache_path()` réutilisée.
+7. Cohérence picker↔spawn : modèles résolvables au spawn = sur-ensemble de ceux du picker (même fichier source).
+
+### Hors périmètre (ne pas faire ici)
+- Résolution providers pour **projets remote (SSH/WSL)** (picker lit déjà le cache hôte — incohérence pré-existante). Fix corrige le cas **local**, ne régresse pas le remote.
+- Déduplication du rendu lifecycle↔infra (`opencode_provider_config_json` ×2) — on factorise **uniquement le seeder**.
+- Aucune modif UI/wizard.
+
+## QA — 2 couches
+1. **Unitaire `application`** (automatisable, déterministe) :
+   - Partie pure `seed_from_bytes(fs, dest, src_bytes)` : bytes présents → assert `<dest>/opencode/models.json` écrit identique ; `None` → aucun fichier **et** pas d'erreur.
+   - Non-régression rendu : JSON de `opencode_config_json` et `opencode_provider_config_json(custom==Some/None)` byte-identiques (tests existants `lifecycle.rs:4428+` verts).
+   - ⇒ Ne prouve **pas** la résolution réelle par OpenCode.
+2. **Intégration / réelle-exécution (gated, propriété QA)** : spawn réel d'OpenCode avec profil `zai` (`custom==None`) contre un cache models.dev fixture contenant `zai` ; assert **pas de fallback glm-5.2** (modèle `zai/<choix>` effectivement utilisé). Gater `#[ignore]`/env (clé API + réseau). **C'est ce test qui prouve le bug corrigé.**
+
+## Risque résiduel + escalade
+- **Inconnu empirique** : est-ce qu'OpenCode au démarrage tente de **rafraîchir** models.dev (écrase notre copie, ou hang sans réseau) ? `OPENCODE_DISABLE_AUTOUPDATE=1` ne vise que l'auto-update du binaire, pas sûr qu'il couvre le refresh models. **QA doit vérifier** sur le test d'intégration. Si le refresh défait B2 → **escalader vers (A)** : capturer `npm`+`baseURL` réels par provider dans le parseur models.dev et peupler `custom`.
+
+## Topologie
+- Branche : `feature/ticket98-opencode-modelsdev-cache-seed` depuis `develop@69e5878` (#97 exclusion mutuelle prérequis y est fusionné : `0f0a76d` + merge `5533073`). `crates/` propre.
+- Carnet #98 version 2 = source de vérité du cadrage.
+
+## Lié
+- #97 (relatesTo) : exclusion mutuelle provider — prérequis livré.

.ideai/memory/tickets-70-100-102-ux-surface-scoping.md

@@ -0,0 +1,51 @@
+---
+name: tickets-70-100-102-ux-surface-scoping
+description: memory note tickets-70-100-102-ux-surface-scoping
+metadata:
+  type: project
+---
+---
+title: Cadrage UX tickets #70 #100 #102 — modèles locaux et bugs terminal
+type: design
+description: Surface utilisateur attendue pour supprimer les modèles llama.cpp téléchargés, et règle UX pour les bugs de scroll/fit OpenCode qui doivent être corrigés sans nouvelle UI.
+---
+
+# Cadrage UX tickets #70 #100 #102
+
+## #70 — Gestion des modèles locaux téléchargés
+
+Ajouter une affordance humaine de suppression des artefacts de modèles téléchargés par les serveurs locaux llama.cpp, dans la surface existante `Local model servers` / configuration OpenCode locale.
+
+Principes visibles :
+- La suppression d'un serveur déclaré et la suppression du fichier modèle téléchargé sont deux actions distinctes.
+- Une action destructive sur le fichier modèle doit être explicite, confirmée, et impossible pendant un usage actif/téléchargement du même artefact.
+- Le libellé doit parler de `modèle téléchargé`, pas de cache interne ou chemin technique en premier niveau.
+- Les modèles issus d'un `localPath` utilisateur ne doivent jamais être proposés à la suppression comme s'ils appartenaient à IdeA.
+
+États attendus par serveur :
+- Aucun modèle téléchargé connu : aucun bouton de suppression de modèle, ou bouton désactivé avec tooltip `Aucun modèle téléchargé par IdeA`.
+- Modèle téléchargé disponible : bouton secondaire/destructif `Supprimer le modèle téléchargé`.
+- Téléchargement/préparation en cours : action désactivée, texte `Téléchargement en cours`.
+- Serveur/agent utilisant ce modèle : action désactivée, texte `Modèle utilisé par un agent en cours`.
+- Suppression en cours : ligne locale occupée, action désactivée, message `Suppression du modèle...`.
+- Succès : toast/status non bloquant `Modèle téléchargé supprimé` ; la configuration serveur reste présente.
+- Échec : alerte inline `Impossible de supprimer le modèle téléchargé : <raison courte>`.
+
+Confirmation :
+- Titre : `Supprimer le modèle téléchargé ?`
+- Corps : `Le serveur local restera configuré, mais IdeA devra retélécharger ce modèle au prochain lancement.`
+- Si la taille est connue : ajouter `Espace libéré : <taille>.`
+- Action principale destructive : `Supprimer le modèle`
+- Action secondaire : `Annuler`
+
+## #100 — Scroll OpenCode
+
+Pas de décision UX spécifique. Le comportement attendu est celui d'une cellule terminal native : l'utilisateur peut remonter dans le scrollback OpenCode jusqu'à la limite de rétention disponible, avec molette, trackpad, scrollbar et clavier, sans blocage prématuré propre à OpenCode.
+
+Ne pas ajouter de bouton, message ou mode spécial OpenCode. QA doit valider le comportement visible dans une cellule OpenCode longue.
+
+## #102 — Fit TUI après switch/layout/ajout cellule
+
+Pas de nouvelle surface UX spécifique. Le terminal doit s'afficher correctement automatiquement après switch de projet, switch de layout, ajout/suppression/split/resize de cellules et rattachement d'une session existante.
+
+Ne pas afficher de message demandant à l'utilisateur de redimensionner. Éviter tout flash durable vide/noir ; un voile technique transitoire n'est acceptable que s'il reste très bref et non bloquant.

.ideai/memory/toolchain-rust-partage-acces-agents.md

@@ -0,0 +1,53 @@
+---
+name: toolchain-rust-partage-acces-agents
+description: memory note toolchain-rust-partage-acces-agents
+metadata:
+  type: project
+---
+---
+slug: toolchain-rust-partage-acces-agents
+title: Accès au toolchain Rust/Tauri partagé pour tous les agents (isolement HOME OpenCode)
+type: project
+description: Le toolchain Rust stable est déjà installé sur la machine mais invisible aux agents car le profil OpenCode isole HOME. Diagnostic, atténuation par symlink, et chantier durable (injection env au spawn).
+---
+
+# Toolchain Rust/Tauri : pourquoi les agents ne compilaient pas, et comment les débloquer
+
+## Symptôme (récurrent)
+Tout agent (Main, DevBackend, QA,…) lancé sous un profil OpenCode ne peut PAS compiler le workspace Rust/Tauri :
+- `cargo`/`rustc` = shims rustup qui répondent « no default toolchain » / « no installed toolchains ».
+- Bloque toute validation backend (cargo check/build/test), fait timeout les délégations lourdes.
+
+## Cause racine
+- Le toolchain **stable 1.94.1 est DÉJÀ installé** dans `/home/anthony/.rustup` + `/home/anthony/.cargo` (toolchains + bin).
+- MAIS le profil **OpenCode isole `HOME`** vers `.ideai/run/<agent_uuid>/.opencode/`. Donc `~/.rustup` et `~/.cargo` = `.opencode/.rustup` / `.opencode/.cargo`, qui ne contiennent qu'un `settings.toml` + un cache registry partiel → **aucun toolchain**.
+- IdeA lui-même ne set **ni** `RUSTUP_HOME` **ni** `CARGO_HOME` (grep vide dans `crates/`). Le point d'extension existe pourtant : `crates/infrastructure/src/session/opencode.rs:237` (`cmd.env(key, value)`) set déjà des env au spawn.
+- `target/` est dans le project root (partagé, géré par le lock cargo) → partageable sans conflit.
+- `tauri` est dispo via `frontend/node_modules/.bin/tauri` (après `npm install` du frontend).
+
+## Atténuation appliquée (2026-07-25, ops, sans rebuild)
+Symlinker les homes isolés vers les homes partagés pour chaque run-dir agent :
+```bash
+for d in .ideai/run/*/.opencode; do
+  for sub in .rustup .cargo; do
+    p="$d/$sub"
+    [ -e "$p" ] && [ ! -L "$p" ] && { rm -rf "$p"; ln -s "/home/anthony/$sub" "$p"; }
+  done
+done
+```
+Vérifié sur Main : `cargo 1.94.1` / `rustc 1.94.1` accessibles **sans aucune variable d'env explicite**. Symlink appliqué aux agents actifs (Main a6ced819, DevBackend 73c853d1, QA aefdbd61, …) — 5 run-dirs concernés.
+
+**Tient pour les agents existants** : rustup suit les symlinks, et OpenCode ne recrée pas `$HOME/.rustup` s'il existe déjà.
+
+## Solution DURABLE (chantier IdeA, à livrer)
+Pour les **nouveaux** agents (IdeA crée un nouveau run-dir `.ideai/run/<uuid>/.opencode/.rustup` vide), il faut qu'IdeA provisionne l'accès au toolchain partagé automatiquement. Deux options équivalentes, à faire par DevBackend + **rebuild AppImage + relance** :
+1. Au spawn de l'agent, injecter `RUSTUP_HOME=/home/anthony/.rustup` et `CARGO_HOME=/home/anthony/.cargo` (point d'extension `opencode.rs:237`). Valeurs résolues depuis le vrai HOME user (pas le HOME isolé), idéalement configurables (env projet / settings).
+2. Ou, à la création du run-dir, créer les deux symlinks `.opencode/.rustup` et `.opencode/.cargo` → homes partagés.
+
+Recommandation : option 1 (injection env) — moteur-agnostique (marche aussi pour Codex/Claude si un jour ils isolent aussi) et ne dépend pas du filesystem layout du moteur.
+
+À grouper dans le **même rebuild AppImage** que le fix « sonde de vivacité multi-moteur » (cf. `idea-memory` à venir) — les deux sont des chantiers runtime qui nécessitent rebuild + relance.
+
+## Liens
+- Règle rebuild AppImage : `.ideai/skills/md/a72dac60-641c-4417-b0d7-94b8539f817a.md` (skill build AppImage), mémoire `mcp-bridge-and-delegation-runtime-notes`.
+- Timeout délégation 600 s (autre symptôme sur les tâches lourdes) : mémoire `rendezvous-600s-cap-too-short-heavy-tasks` + sonde Claude-seule `crates/infrastructure/src/inspector/claude_paths.rs:89`.

.ideai/memory/ux-ai-profiles-opencode-persistence-list-coherence.md

@@ -0,0 +1,41 @@
+---
+name: ux-ai-profiles-opencode-persistence-list-coherence
+description: memory note ux-ai-profiles-opencode-persistence-list-coherence
+metadata:
+  type: project
+---
+---
+title: UX — Cohérence profils IA/OpenCode entre éditeur et picker agents
+type: decision
+description: Décisions de surface pour corriger la création de profils OpenCode, la persistance visible après sauvegarde et la cohérence entre Settings > Profils IA et les sélecteurs d'agents.
+---
+
+# UX — Profils IA/OpenCode : création, persistance, liste unique
+
+## Décision centrale
+La liste visible dans `Settings > Profils IA` et les pickers de profils des agents doit représenter la même collection persistée de profils IA. Les profils de référence ne sont qu'une source d'ajout, pas une deuxième vérité visible.
+
+## Comportement attendu
+- Le bouton de création OpenCode s'appelle `Créer un profil OpenCode` dans la surface française.
+- Cliquer sur ce bouton ajoute immédiatement une ligne de profil en brouillon, sélectionnée, éditable et clairement marquée non enregistrée tant que la sauvegarde n'a pas réussi.
+- Chaque nouveau profil OpenCode doit avoir une identité distincte et un nom humain distinct par défaut, par exemple `OpenCode local 2`; l'utilisateur peut renommer avant sauvegarde.
+- `Dupliquer` conserve la configuration du profil source mais crée une nouvelle identité et un nom suffixé, par exemple `(copie)`.
+- `Enregistrer` persiste tous les profils sélectionnés/édités, puis recharge la liste depuis la source persistée. La liste affichée après succès doit être le résultat relu, pas seulement l'état local optimiste.
+- Après sauvegarde réussie, le profil créé reste visible dans l'éditeur sans réouverture manuelle et apparaît dans le picker de création d'agent et dans le picker de changement de profil d'un agent existant.
+- Les profils OpenCode ne doivent jamais être fusionnés/dédupliqués par commande, modèle, endpoint ou adapter. La déduplication visible se fait uniquement par `id`.
+- En mode édition, les profils déjà configurés apparaissent en premier, pré-sélectionnés, avec leur configuration réelle intacte. Les profils de référence non configurés peuvent suivre comme suggestions non sélectionnées.
+- Si un profil référencé par un agent n'existe plus dans la liste persistée, le picker de l'agent conserve l'id courant comme option orpheline lisible, sans le mélanger aux profils disponibles.
+
+## États et feedback
+- Pendant la création/clonage : bouton désactivé ou loading local, sans bloquer la détection CLI.
+- Ligne brouillon : indicateur discret `Non enregistré` ou état visuel équivalent.
+- Sauvegarde réussie : statut court `Profils enregistrés` puis disparition automatique.
+- Échec sauvegarde : message d'erreur persistant, la ligne brouillon reste éditable et n'est pas perdue.
+- Picker agents vide : ne pas encourager la saisie libre d'id comme chemin normal. Afficher plutôt un état vide actionnable vers `Profils IA`.
+
+## Critères d'acceptation visuels
+- Créer un profil OpenCode, sauvegarder, rester sur Settings : le profil est toujours visible après le retour succès.
+- Sans fermer Settings, ouvrir/créer un agent : le même profil est disponible dans le picker.
+- Deux profils OpenCode avec même endpoint/modèle mais ids distincts restent deux lignes et deux options distinctes.
+- Renommer un profil puis sauvegarder met à jour le libellé dans l'éditeur et dans les pickers agents.
+- Aucun écran ne montre simultanément une liste issue seulement des références et une liste issue des profils persistés comme si elles étaient équivalentes.

.ideai/memory/web-client-is-single-column-no-desktop-shell.md

@@ -0,0 +1,44 @@
+---
+name: web-client-is-single-column-no-desktop-shell
+description: memory note web-client-is-single-column-no-desktop-shell
+metadata:
+  type: project
+---
+# Le client web n'a pas de shell desktop (ni docks, ni layout grid)
+
+Constat établi en livrant le ticket #69 (adaptibilité téléphone), sur `develop @ 506d589`.
+
+## Le fait
+
+Le client web livré par #13 (`VITE_TRANSPORT=http`) **n'a jamais eu** de docks
+gauche/droite, de fenêtres flottantes, de `LayoutTree`, de tabs projet, de menus ni
+de toasts. `main.tsx` route `isWeb` vers `WebApp`, qui est une surface autonome :
+
+- `WebApp` → `PairingScreen` **ou** `WebWorkspace` (rien d'autre) ;
+- `WebWorkspace` → une **colonne verticale unique** (`flex flex-col overflow-y-auto`) ;
+- `WebAgentCell` → `TerminalView`.
+
+Les seuls imports `@/features/*` de tout `features/web/` sont `terminals` et
+`workstate/useProjectWorkState`. Le shell desktop (`App`, layout, docks) n'est
+atteignable que par la branche non-web de `main.tsx`.
+
+## Pourquoi ça compte
+
+Le cadrage de #69 prévoyait un lot « remplacer les docks gauche/droite/floating par
+une pile verticale, drawer ou bottom sheet ». Ce lot était **sans objet** : il n'y a
+pas de dock à remplacer, et l'arbitrage produit « bottom sheet vs drawer » ne se pose
+pas sur cette surface. Le vrai travail téléphone était ailleurs (terminal xterm
+pilotable au doigt, `dvh`, safe-area, rangées qui débordent à 360px).
+
+**Avant de cadrer un ticket « responsive / mobile » sur le client web, partir de
+`features/web/`, pas du shell desktop.** Les deux surfaces ne partagent que
+`TerminalView` et les hooks transport-neutres.
+
+## Garde en place
+
+`frontend/src/features/web/WebMobile.test.tsx` épingle la frontière : le client web
+ne doit monter aucun `layout-grid` / `layout-grid-container` / `layout-split` /
+`layout-tabs`. Si un jour on veut du desktop-shell dans le web, ce test tombe — et
+c'est le signal qu'il faut re-cadrer, pas le supprimer.
+
+Voir aussi [[ui-rework-sprint-scoping-contracts]].

.ideai/permissions.json

@@ -187,6 +187,44 @@
         ],
         "fallback": "allow"
       }
+    },
+    {
+      "agentId": "5d07e4a7-8676-4a71-aea1-5b64caefa944",
+      "permissions": {
+        "rules": [
+          {
+            "capability": "read",
+            "effect": "allow",
+            "paths": [
+              "**"
+            ],
+            "commands": []
+          },
+          {
+            "capability": "write",
+            "effect": "deny",
+            "paths": [
+              "**"
+            ],
+            "commands": []
+          },
+          {
+            "capability": "delete",
+            "effect": "deny",
+            "paths": [
+              "**"
+            ],
+            "commands": []
+          },
+          {
+            "capability": "executeBash",
+            "effect": "allow",
+            "paths": [],
+            "commands": []
+          }
+        ],
+        "fallback": "allow"
+      }
     }
   ]
 }

.ideai/skills/index.json

@@ -5,13 +5,8 @@
       "id": "a72dac60-641c-4417-b0d7-94b8539f817a",
       "name": "build-appimage",
       "description": null,
-      "contentHash": "77cb33b978b242f6"
-    },
-    {
-      "id": "86ea97df-1533-47e5-8809-dc2b02242567",
-      "name": "mcp-rendezvous-functional-test",
-      "description": null,
-      "contentHash": "9fc8260f64c3b9d5"
+      "kind": "workflow",
+      "contentHash": "56dd74230ccf517d"
     }
   ]
-}
+}

.ideai/skills/md/6883638f-8f0e-4adf-b78b-ead2fba71a01.md

@@ -0,0 +1 @@
+Skill de test

.ideai/skills/md/a72dac60-641c-4417-b0d7-94b8539f817a.md

@@ -1,6 +1,6 @@
 # Build de l'AppImage IdeA (Linux)
 
-Commande **validée bout-en-bout** (2026-06-17, build exit 0, artefact 106M produit) pour reconstruire l'AppImage Linux d'IdeA. À utiliser à chaque fois qu'un correctif backend/front doit être rendu actif dans l'app (rappel : **le binaire qui tourne = l'AppImage installée, pas les sources** — un correctif n'est actif qu'après rebuild + remplacement + relance d'IdeA).
+Commande **validée bout-en-bout** (mise à jour 2026-08-03) pour reconstruire l'AppImage Linux d'IdeA. À utiliser à chaque fois qu'un correctif backend/front doit être rendu actif dans l'app (rappel : **le binaire qui tourne = l'AppImage installée, pas les sources** — un correctif n'est actif qu'après rebuild + remplacement + relance d'IdeA).
 
 ## Procédure (2 étapes, depuis le project root `/home/anthony/Documents/Projects/IdeA`)
 
@@ -12,16 +12,18 @@ npm --prefix frontend run build
 ### 2. Bundle Tauri AppImage (depuis `crates/app-tauri/`)
 ```bash
 cd crates/app-tauri
-APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage
+mkdir -p /tmp/idea-cargo-home
+CARGO_HOME=/tmp/idea-cargo-home APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage
 ```
 
 ## Pourquoi ces options (ne pas les retirer)
 - `--bundles appimage` : **exclut NSIS** (installeur Windows) — sinutile et cassant sur Linux.
 - `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1` : **workaround FUSE obligatoire**. Sans ça, l'étape finale `linuxdeploy` (elle-même une AppImage montée via FUSE) échoue avec `failed to run linuxdeploy`. Le compile Rust réussit avant ce point ; seul le bundling casse (l'`AppDir` est généré mais pas le `.AppImage`).
+- `CARGO_HOME=/tmp/idea-cargo-home` : **workaround sandbox/permissions** pour les environnements où `/home/<user>/.cargo` est monté en lecture seule. Sans ça, `tauri build` peut échouer pendant le téléchargement/unpack Cargo avec `Read-only file system (os error 30)`.
 
 ## Artefact produit
 ```
-target/release/bundle/appimage/IdeA_0.1.0_amd64.AppImage
+target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
 ```
 (Le build est long : compile Rust release ~1 min + bundling. Lancer en arrière-plan.)
 
@@ -29,4 +31,4 @@ target/release/bundle/appimage/IdeA_0.1.0_amd64.AppImage
 Pour rendre le correctif actif, il faut **remplacer l'AppImage installée** `/home/anthony/Documents/IdeA_0.1.0_amd64.AppImage` par l'artefact, puis **relancer IdeA**. ⚠️ Relancer IdeA **tue l'orchestrateur en cours** (le serveur qui héberge la session active et les ponts MCP) : à faire par l'utilisateur quand il est prêt, pas en pleine session multi-agents. Garder un backup de l'ancienne AppImage avant remplacement (cf. convention `.old-<raison>`).
 
 ## Piège env (si on lance un binaire ensuite)
-La session shell hérite des variables de l'AppImage montée (`APPDIR`, `LD_LIBRARY_PATH`, `PYTHONHOME` → `/tmp/.mount_IdeA_*`). Pour lancer un binaire app-tauri compilé sans crash WebKit, partir d'un env propre (`env -i PATH=/usr/bin:/bin HOME=$HOME XDG_RUNTIME_DIR=/run/user/1000 …`) et préférer `jq` à `python3`.
+La session shell hérite des variables de l'AppImage montée (`APPDIR`, `LD_LIBRARY_PATH`, `PYTHONHOME` → `/tmp/.mount_IdeA_*`). Pour lancer un binaire app-tauri compilé sans crash WebKit, partir d'un env propre (`env -i PATH=/usr/bin:/bin HOME=$HOME XDG_RUNTIME_DIR=/run/user/1000 …`) et préférer `jq` à `python3`.

.ideai/skills/md/eb76ce50-c05c-443b-8ba5-36bda091a148.md

@@ -0,0 +1,111 @@
+# Build de l'AppImage IdeA (Linux)
+
+Procédure canonique pour reconstruire l'AppImage Linux d'IdeA et les bundles frontend associés.
+
+À utiliser à chaque fois qu'un correctif doit être visible dans l'app desktop. Rappel produit : **le binaire qui tourne = l'AppImage installée, pas les sources**. Un correctif source n'est actif dans l'app desktop qu'après rebuild, remplacement de l'AppImage utilisée, puis relance d'IdeA.
+
+## Commande principale
+
+Depuis le project root `/home/anthony/Documents/Projects/IdeA` :
+
+```bash
+cd crates/app-tauri
+APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage
+```
+
+Cette commande déclenche `build.beforeBuildCommand`, donc elle reconstruit automatiquement les deux bundles frontend :
+
+- `frontend/dist` : bundle desktop, transport `tauri`.
+- `frontend/dist-web` : bundle web, transport `http`.
+
+Ne pas revenir à l'ancienne procédure `npm --prefix frontend run build` seule : elle ne reconstruit pas le bundle web séparé.
+
+## Vérification des bundles web/desktop
+
+Après le build, lancer :
+
+```bash
+npm --prefix frontend run test:bundle-transport
+```
+
+Sortie attendue :
+
+```text
+dist: __IDEA_TRANSPORT__="tauri" (1 marker)
+dist-web: __IDEA_TRANSPORT__="http" (1 marker)
+```
+
+## Artefact attendu
+
+```text
+target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
+```
+
+Vérifier rapidement :
+
+```bash
+ls -lh target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
+APPIMAGE_EXTRACT_AND_RUN=1 target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage --appimage-help | head
+```
+
+## Pourquoi ces variables sont obligatoires
+
+- `--bundles appimage` : cible uniquement l'AppImage Linux et évite les bundles inutiles/cassants comme NSIS.
+- `NO_STRIP=true` : évite l'échec linuxdeploy/strip sur les bibliothèques système modernes contenant `.relr.dyn`.
+- `APPIMAGE_EXTRACT_AND_RUN=1` : évite l'échec FUSE quand linuxdeploy ou appimagetool ne peuvent pas monter une AppImage dans l'environnement courant.
+
+## Fallback si Tauri échoue à `failed to run linuxdeploy`
+
+Symptôme : la commande Tauri reconstruit `frontend/dist`, `frontend/dist-web`, compile `target/release/app-tauri`, crée `target/release/bundle/appimage/IdeA.AppDir`, puis échoue seulement à l'étape finale :
+
+```text
+failed to bundle project `failed to run linuxdeploy`
+```
+
+Ne pas réanalyser tout le build. Faire ce diagnostic court :
+
+```bash
+APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=true LDAI_OUTPUT=/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage \
+  /home/anthony/.cache/tauri/linuxdeploy-x86_64.AppImage \
+  --appdir /home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir \
+  --output appimage
+```
+
+Si `appimagetool` échoue avec téléchargement runtime impossible :
+
+```text
+Failed to download runtime file
+```
+
+utiliser le runtime local déjà en cache et l'`appimagetool` extrait. Chercher le dossier extrait récent :
+
+```bash
+find /tmp -path '*/appimagetool-prefix/usr/bin/appimagetool' -type f -printf '%p\n' | tail -1
+```
+
+Puis lancer en remplaçant `<EXTRACTED>` par le préfixe trouvé, par exemple `/tmp/appimage_extracted_xxx` :
+
+```bash
+PATH=<EXTRACTED>/appimagetool-prefix/usr/bin:$PATH \
+ARCH=x86_64 \
+<EXTRACTED>/appimagetool-prefix/usr/bin/appimagetool \
+  --runtime-file /home/anthony/.cache/tauri/runtime-x86_64 \
+  /home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir \
+  /home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
+```
+
+Le `PATH` est nécessaire parce que `mksquashfs` est fourni dans `appimagetool-prefix/usr/bin` et peut être absent du PATH système.
+
+## Relance de l'application
+
+Ne pas relancer IdeA automatiquement depuis une session active : cela tue l'orchestrateur courant et les ponts MCP. Une fois l'AppImage reconstruite, l'utilisateur décide quand remplacer/lancer l'artefact final.
+
+## Piège d'environnement AppImage
+
+Une session shell lancée depuis l'AppImage peut hériter de variables comme `APPDIR`, `LD_LIBRARY_PATH`, `PYTHONHOME` pointant vers `/tmp/.mount_IdeA_*`. Symptômes possibles : `python3` casse avec `No module named 'encodings'`, ou un binaire Tauri local se lance dans un environnement pollué.
+
+Pour des commandes sensibles, préférer un environnement propre ou éviter Python :
+
+```bash
+env -i PATH=/usr/bin:/bin HOME=$HOME XDG_RUNTIME_DIR=/run/user/1000 <commande>
+```

.ideai/system-permissions.json

@@ -0,0 +1,6 @@
+{
+  "version": 1,
+  "projectDefault": {
+    "network": "allow"
+  }
+}

.ideai/tickets/100/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#100"
+version: 3
+updatedBy: {"kind":"user"}
+updatedAt: 1784993984569
+---

.ideai/tickets/100/issue.md

@@ -0,0 +1,16 @@
+---
+id: "4709958c-5082-44fd-a1fd-d6bad85f9361"
+number: 100
+title: "[Bug] Problème sur le scroll des agents OpenCode"
+status: "closed"
+priority: "high"
+sprint: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
+links: []
+agentRefs: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1784992615586
+updatedAt: 1785083912470
+version: 4
+---
+Quand un agent est un agent opencode, je ne peux aps scroll très haut dans sa cellule.

.ideai/tickets/101/carnet.md

@@ -0,0 +1,96 @@
+---
+issueRef: "#101"
+version: 7
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1785011116365
+---
+# Carnet #101 — défaut d'isolation multi-projet (cause racine figée)
+
+> Diagnostic Architect (2026-07-25). Source de vérité du fix. Mémoire durable :
+> `ticket101-cross-talk-multi-project-rootcause`.
+
+## Cause racine
+Stores disque IdeA **correctement scoppés par projet** (mémoire, contexte, handoff, live-state lus
+depuis `input.project.root` ; agents persistés dans `.ideai/agents.json` par root projet, **sans
+re-mint des UUID à l'ouverture**). Mais plusieurs **registres mémoire runtime restent globaux,
+indexés par `AgentId` seul** → deux projets ouverts (surtout si l'un est une copie) peuvent porter
+les **mêmes `AgentId`** et le runtime les confond.
+
+### 2 manifestations, même défaut
+- **A — contamination du contexte d'inférence** : conversation/session d'un projet réutilisée pour
+  l'autre → contexte injecté à l'agent contaminé (preuve : pseudo-branche `wear-os-watch-sync`
+  créée par l'agent Git avec un nom de l'autre projet).
+- **B — notification de tâche backend perdue / agent s'arrête** (sujet original) : complétion
+  livrable/bloquée/réveillant la mauvaise session.
+
+## Points précis (registres par `AgentId` seul à requalifier)
+- ConversationRegistry global + `ConversationId` dérivé des UUID agents seuls :
+  `crates/domain/src/conversation.rs:71`, `crates/infrastructure/src/conversation/mod.rs:41`,
+  orchestrateur `crates/application/src/orchestrator/service.rs:2192` (et `:2293`, `:2368`).
+- Sessions PTY/structured par `agent_id` seul :
+  `crates/application/src/terminal/registry.rs:182,437`.
+- Verrous ask / busy-state / liveness / délégations différées :
+  `crates/application/src/orchestrator/service.rs:418`,
+  `crates/infrastructure/src/input/mod.rs:47`.
+- Inbox/mailbox par `AgentId` seul : `crates/domain/src/inbox.rs:68,156`,
+  `crates/infrastructure/src/input/mod.rs:1052`, `crates/infrastructure/src/mailbox/mod.rs:44`.
+- Wake par `AgentId` seul : `crates/application/src/orchestrator/wake.rs:87`,
+  provider `crates/backend/src/lib.rs:687`.
+
+### Pour B — distinction runtime vs modèle
+La chaîne sink→`project_id`→wake est **correcte** jusqu'au bridge
+(`crates/infrastructure/src/background_task/sink.rs:23,142` ; `crates/backend/src/lib.rs:2228`
+recharge le projet par `project_id` puis `wake_agent`). Le défaut réapparaît juste après
+(inbox/mailbox/busy/session par AgentId seul). **Runtime IdeA suspecté en premier.** GLM 5.2 n'est
+l'hypothèse principale que si les logs prouvent enqueue+wake+`BackgroundTaskCompletionDelivered`
+sur le bon projet sans reprise. Traces : `lib.rs:2238`, `wake.rs:93`.
+
+## Décision utilisateur
+**Lancer le fix structurel maintenant (lots 1-2).** La collision d'UUID et les logs B se
+vérifieront en parallèle.
+
+## Périmètre DevBackend (lots 1-2 de ce fix)
+- **Lot 1** : introduire une clé runtime scellée `RuntimeAgentKey { project_id, agent_id }` ;
+  interdire toute map app-wide indexée par `AgentId` seul.
+- **Lot 2** : propager la clé dans `AgentInbox`, `InputMediator`, `AgentMailbox`,
+  busy/liveness/deferred, wake, session lookup, ask-locks. **Correctif structurel commun à A et B.**
+
+Lots suivants (3-6, hors premier passage) : qualifier ConversationId/registry par projet (lot 3) ;
+requalifier `TerminalSessions`/`StructuredSessions` par `(project_id, agent_id)` +
+`AppWakeSessionProvider` refuse l'autre projet (lot 4) ; audit `session_limit`/tables reprise (lot 5) ;
+télémétrie `project_id` sur logs diag wake/routage (lot 6).
+
+## Invariants
+- Sources de contexte sur disque restent root-scopées (ne pas régresser).
+- Templates/profils globaux restent globaux produit (pas de vecteur de session/conversation partagée).
+- Un projet non-actif doit continuer à recevoir ses wakes et complétions.
+- Pas de régression OpenCode/Codex/Claude (correctif transverse runtime, pas moteur-spécifique).
+- Aucun nouveau DTO frontend pour la correction minimale.
+
+## QA — critère de vérité
+Test d'intégration **non-cross-talk** : 2 projets ouverts avec **volontairement les mêmes `AgentId`** :
+- délégation projet A ne réutilise jamais session/conversation vivante de projet B ;
+- complétion `(projet A, agent X)` n'entre ni dans l'inbox ni dans la session de `(projet B, agent X)` ;
+- wake d'un projet non-actif fonctionne ;
+- collision d'ids qui échouait avant → verte sur PTY, structured et background wake.
+
+## Clôture 2026-07-25
+- Correctif livré sur `feature/ticket101-multi-project-isolation` puis mergé localement dans `develop`.
+- Commit feature : `6e98fd8 fix(runtime): isolate agent state by project (#101)`.
+- Merge local : `merge: integrate ticket 101 multi-project isolation`.
+- QA ciblée verte :
+  - `cargo test -p application --test agent_wake --test orchestrator_service --test structured_registry_d1 --test structured_launch_d3 --test session_limit_service --test session_limit_t4 --test workstate --test workstate_actions`
+  - `cargo test -p infrastructure --test agent_inbox --test mcp_server`
+  - `cargo test -p app-tauri --test session_limit_wiring`
+  - `cargo test -p application`
+  - `cargo test -p app-tauri --tests`
+- Réserve connue : `cargo test -p infrastructure` complet reste rouge dans le sandbox QA sur tests `openai_compat` à cause du bind local interdit (`Operation not permitted`), sans signal de régression #101.
+
+## Hors périmètre
+- #91 (popup de notification) : purement front, indépendant.
+- Remint systématique des AgentId à l'ouverture : non retenu (la clé runtime rend la collision
+  inoffensive même sans remint).
+
+## Lié
+- #91 (relatesTo). Mémoires : `background-tasks-first-class-design`, `b8-command-runner-pty-framing`,
+  `mcp-bridge-and-delegation-runtime-notes` (règle rebuild AppImage).

.ideai/tickets/101/issue.md

@@ -0,0 +1,16 @@
+---
+id: "05f9f05b-97d4-4ae2-9fd9-220dd71f7231"
+number: 101
+title: "[Bug] Soucis de retour de notification sur les taches backend"
+status: "closed"
+priority: "critical"
+sprint: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+createdAt: 1784993230013
+updatedAt: 1785011116365
+version: 7
+---
+Lorsque un agent Opencode lance une tache backend, il s'arrete de travailler et je ne suis pas sur q'uil y ai un jour un retour de notification. Je ne sais aps si le soucis provient de OpenCode ou s'il provient du model (GLM 5.2 ici)

.ideai/tickets/102/carnet.md

@@ -0,0 +1,38 @@
+---
+issueRef: "#102"
+version: 11
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1785878554632
+---
+## 2026-08-04 — Réouverture
+
+- Repro utilisateur confirmée: en changeant de projet, si une cellule contient un terminal d'agent IA et que du contenu est arrivé pendant que le projet n'était pas affiché, le terminal revient partiellement/blanc/tronqué.
+- Symptôme visuel observé: le contenu complet réapparaît immédiatement après un resize de la cellule ou de la fenêtre.
+- Portée repro indiquée historiquement: switch de projet, switch de layout, ajout/suppression/redécoupage de cellules; le cas prioritaire confirmé aujourd'hui est le retour sur projet.
+- Hypothèse de travail à valider: problème de refresh/fit/reflow frontend du terminal lors de la ré-attache ou ré-activation de la vue, pas un manque de données côté agent.
+- Action en cours: recadrage Architect, décision de branche Git, implémentation dev ciblée, puis validation QA sur reproduction réelle.
+
+## 2026-08-04 — Cadrage Architecture (analyse statique, avant implémentation)
+
+- Frontière validée: frontend pur, ciblée sur `frontend/src/features/terminals/TerminalView.tsx`.
+- Le backend/PTY n'est pas suspecté à ce stade: le tail de scrollback est bien restitué au reattach; le défaut semble être de rendu/reflow au retour sur la vue.
+- Point d'attention principal: `term.write(scrollback)` pourrait arriver avant le premier `fit()` réellement utile, ce qui laisserait xterm wrapper le contenu sur une géométrie transitoire et n'obtiendrait un repaint correct qu'au resize manuel ultérieur.
+- Les correctifs précédents ont déjà renforcé la boucle de fit; le trou probable est l'absence de test sur le rendu/repaint effectif et sur l'ordre `reattach/write` vs `first useful fit`.
+- Stratégie recommandée: corriger dans `TerminalView` l'ordre de réécriture du scrollback et/ou forcer un repaint plein-buffer après le premier fit utile, puis valider par test ciblé et repro réelle.
+
+## 2026-08-04 — Implémentation DevFrontend
+
+- Correctif appliqué dans `frontend/src/features/terminals/TerminalView.tsx`.
+- Changement clé: en cas de `reattach`, le scrollback et les chunks live reçus pendant la fenêtre de réattache ne sont plus écrits immédiatement dans xterm; ils sont tamponnés jusqu'au premier `fit` utile, puis rejoués dans l'ordre `scrollback` puis `live output`.
+- Objectif: éviter un rendu initial du buffer sur une géométrie transitoire et supprimer la dépendance à un resize manuel ultérieur pour déclencher l'affichage correct.
+- Test ajouté/ajusté dans `frontend/src/features/terminals/TerminalView.test.tsx` pour verrouiller qu'aucun `term.write` ne précède le premier `fit` utile et que l'ordre de replay est conservé.
+
+## 2026-08-04 — Verdict QA
+
+- Validation automatisée verte:
+  - `cd frontend && npx vitest run src/features/terminals/TerminalView.test.tsx` -> 22 tests passés.
+  - `cd frontend && npx vitest run src/features/terminals/TerminalView.scrollback.test.tsx src/features/terminals/TerminalView.portal.test.tsx` -> 5 tests passés.
+  - `cd frontend && npx vitest run src/features/terminals` -> 39 tests passés.
+  - `cd frontend && npx vitest run` -> 115 fichiers, 1083 tests passés.
+- Verdict QA: `vert avec réserve de preuve manuelle`.
+- Réserve restante: absence de repro visuelle réelle rejouée dans l'application avec un vrai xterm, une session vivante, puis un reattach après switch projet/layout. Le ticket reste donc ouvert tant que cette validation de terrain n'est pas obtenue.

.ideai/tickets/102/issue.md

@@ -0,0 +1,17 @@
+---
+id: "e91fd358-da94-4382-aa70-6a3fe5a63840"
+number: 102
+title: "[Bug] Devoir resize les cellule pour afficher la TUI d'un agent"
+status: "inProgress"
+priority: "medium"
+sprint: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1784993319700
+updatedAt: 1785878554632
+version: 11
+---
+J'ai toujours un soucis qui fait que quand je switch de projet IdeA ou de layout ou que j'ajoute des cellules ou autres, je suis obligé de resize un coup la cellule pour que son constenu s'affiche correctement

.ideai/tickets/103/carnet.md

@@ -0,0 +1,99 @@
+---
+issueRef: "#103"
+version: 5
+updatedBy: {"kind":"user"}
+updatedAt: 1785271085635
+---
+# Carnet #103 — permission réseau exposée dans IdeA
+
+## Problème
+Certaines commandes lancées par les agents s'exécutent dans un environnement où le réseau est restreint, sans visibilité ni action claire dans IdeA. Exemple live : rebuild AppImage OK jusqu'au bundling, puis `appimagetool` échoue à télécharger le runtime GitHub car la session agent est `network restricted` + `approval policy: never`.
+
+## Décision UX
+Mémoire : `ticket103-network-permission-ux-surface`.
+
+- Surface principale : `Permissions > Système`.
+- Miroirs de lecture : badge compact dans `Agents`, bannière/erreur contextualisée dans `Terminal`.
+- États visibles : `Réseau autorisé`, `Réseau interdit`, `Demande d'autorisation`, `Verrouillé par le runtime`.
+- Distinction obligatoire : politique voulue, état effectif, verrou runtime.
+- Si le runtime externe ne permet pas l'élévation dans la session active : contrôle read-only + explication explicite.
+
+## Cadrage architecture
+Ne pas étendre le modèle existant `ProjectPermissions` fichier/bash : le réseau n'est ni une capability filesystem ni une règle Landlock. Ajouter un modèle/read-model séparé de permissions système.
+
+### Domaine / DTO V1
+- `NetworkPolicy = "allow" | "deny" | "ask"`.
+- `SystemPermissionSet { network?: NetworkPolicy }`.
+- `ProjectSystemPermissions { version, projectDefault?: SystemPermissionSet, agents?: [{ agentId, permissions: SystemPermissionSet }] }`.
+- `ResolvedAgentSystemPermissions` :
+  - `wanted: NetworkPolicy | null`
+  - `effective: NetworkPolicy`
+  - `runtimeLock: { state: "none" | "locked", source?: string, reason?: string }`
+  - `control: { mode: "editable" | "readOnly", reason?: string }`
+
+### Ports / use cases
+- `SystemPermissionStore`.
+- `GetProjectSystemPermissions`.
+- `UpdateProjectSystemPermissions`.
+- `UpdateAgentSystemPermissions`.
+- `ResolveAgentSystemPermissions`.
+- `RuntimePermissionProbe` : expose ce que le runtime hôte/fournisseur autorise réellement et s'il verrouille le réseau.
+
+### API/commands attendus
+- `get_project_system_permissions(projectId) -> ProjectSystemPermissionsDto`
+- `update_project_system_permissions({ projectId, permissions }) -> ProjectSystemPermissionsDto`
+- `update_agent_system_permissions({ projectId, agentId, permissions }) -> ProjectSystemPermissionsDto`
+- `resolve_agent_system_permissions({ projectId, agentId }) -> ResolvedAgentSystemPermissionsDto`
+
+### Limite produit V1
+Implémentable maintenant : persister la politique voulue, afficher `wanted/effective/runtimeLock`, rendre le contrôle read-only si runtime verrouillé/non inspectable, badges agents, bannière terminal.
+
+Non promis en V1 : changer effectivement la permission réseau d'une session fournisseur déjà lancée ou élever un runtime externe `network restricted` / `approval never`. IdeA doit l'expliquer plutôt que simuler une élévation.
+
+## Découpage
+### DevBackend
+1. Ajouter domaine `system permissions` séparé de LP1 permissions fichier/bash.
+2. Ajouter store + use cases + DTO + commands Tauri/HTTP.
+3. Ajouter `RuntimePermissionProbe` read-only au composition root.
+4. Ajouter read-model `resolve_agent_system_permissions`.
+5. Optionnel si simple : mapper des échecs réseau vers un code stable `NETWORK_LOCKED` ou `NETWORK_UNAVAILABLE`.
+
+### DevFrontend
+1. Étendre types domaine, ports, adapters Tauri/HTTP/mock.
+2. Ajouter la sous-section `Réseau` dans `Permissions > Système`.
+3. Ajouter badge compact dans `Agents`.
+4. Ajouter bannière/erreur terminal contextualisée pour état verrouillé/échec réseau.
+
+### QA
+- Projet sans config : état cohérent, pas de faux `allow`.
+- Save project default puis override agent : relecture identique.
+- Resolve distingue `wanted`, `effective`, `runtimeLock`.
+- Probe `locked` : contrôle read-only + message visible.
+- Non-régression `Permissions > Système` existant fichier/bash.
+- Aucun moteur ne reçoit de faux flag réseau au spawn.
+- Badge agents et bannière terminal reflètent l'état effectif.
+
+## Validation 2026-07-25
+QA verte sur le périmètre #103.
+
+Commandes exécutées par QA :
+- `cargo test -p domain system_permissions`
+- `cargo test -p application --test system_permission_usecases`
+- `cargo test -p infrastructure --test system_permission_store`
+- `cargo test -p app-tauri --test dto_system_permissions`
+- `cargo test -p web-server allowlisted`
+- `npm run typecheck`
+- `npx vitest run src/features/permissions/permissions.test.tsx src/features/agents/agents.test.tsx src/features/terminals/TerminalView.test.tsx`
+- `npx vitest run src/features/permissions/permissions.test.tsx`
+
+Résultats : backend ciblé vert, frontend typecheck vert, tests frontend ciblés 49 passed.
+
+## État Git
+Implémentation validée dans le working tree courant, mais commit/merge non réalisé par Main :
+- l'agent Git headless renvoie un pseudo-appel outil au lieu d'agir ;
+- Main ne peut pas écrire `.git/index.lock` depuis cette session (`Read-only file system`).
+
+Le commit local reste à faire manuellement ou via un agent Git fonctionnel.
+
+## Critère de clôture
+Tests pertinents verts, commit/merge local par Git, puis rebuild AppImage.

.ideai/tickets/103/issue.md

@@ -0,0 +1,39 @@
+---
+id: "3d9021da-26c3-439d-9463-8d206bd06f1b"
+number: 103
+title: "Exposer et piloter la permission réseau des agents/commandes dans IdeA"
+status: "closed"
+priority: "high"
+sprint: null
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785011668081
+updatedAt: 1785271085635
+version: 5
+---
+## Problème
+
+Aujourd'hui certaines commandes lancées par les agents s'exécutent dans un environnement où le réseau est restreint, sans que l'utilisateur puisse le voir ni l'autoriser depuis IdeA. Exemple réel : rebuild AppImage OK jusqu'au bundling, puis `appimagetool` échoue à télécharger le runtime AppImage depuis GitHub (`Failed to download runtime: server returned status code 0`) parce que la session agent a `network restricted` et `approval policy: never`.
+
+## Besoin utilisateur
+
+Depuis IdeA, l'utilisateur doit pouvoir comprendre et piloter cette permission réseau :
+- voir qu'un agent/profil/session est en mode réseau interdit ou autorisé ;
+- configurer la politique réseau attendue pour les agents/commandes ;
+- éviter les échecs opaques de commandes qui ont légitimement besoin d'Internet (build, install, téléchargement runtime, docs, dépendances) ;
+- conserver un comportement sûr par défaut et explicite.
+
+## Attendu produit
+
+Définir puis implémenter une surface IdeA pour exposer cette permission. La solution doit respecter le modèle de permissions/sandbox existant et clarifier la limite éventuelle : si le sandbox fournisseur impose `network restricted` sans possibilité d'élévation runtime, IdeA doit l'expliquer plutôt que faire croire que le réseau est activable.
+
+## Critères d'acceptation
+
+- Une surface UI ou configuration explicite permet de voir la politique réseau applicable aux agents/commandes.
+- L'utilisateur dispose d'une action ou d'un réglage clair quand IdeA peut piloter cette permission.
+- Si la permission est imposée par le runtime externe et non modifiable, l'UI l'indique clairement.
+- Les agents/commandes ne gagnent pas l'accès réseau silencieusement.
+- Tests pertinents verts.
+- AppImage reconstruite après livraison.

.ideai/tickets/107/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#107"
+version: 4
+updatedBy: {"kind":"user"}
+updatedAt: 1785271098557
+---

.ideai/tickets/107/issue.md

@@ -0,0 +1,17 @@
+---
+id: "6a79006b-0201-4176-ae54-39a05cc3baa6"
+number: 107
+title: "[Bug] croisement entre les projet des retours des agents"
+status: "closed"
+priority: "critical"
+sprint: null
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"user"}
+createdAt: 1785136727824
+updatedAt: 1785271098557
+version: 4
+---
+Il y a un soucis très important que j'ai constatés. J'ai actuellement 2 projets ouverts: IdeA et GameTime. Les deux projets travaillaient en même temps et j'ai vu GameTime qui semblait récupérer une requete du projet IdeA. Pour plus de précision, sur mes deux projets, j'ai un agent Git qui utilise OpenCode et un modelle local llamacpp, et j'ia eu l'impression qu'ils ont tous les deux appelé leur agent Git mais GameTime à recus la réponse de IdeA car la réponse parlait d'une branche du projet IdeA.
+Je ne suis pas totalement sur de ce que j'avance, la seule chose dont je suis sur, c'est que GameTime s'est vu adressé une réponse qui était déstinée au projet IdeA.

.ideai/tickets/108/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#108"
+version: 3
+updatedBy: {"kind":"user"}
+updatedAt: 1785328001206
+---

.ideai/tickets/108/issue.md

@@ -0,0 +1,17 @@
+---
+id: "d5953745-406f-406f-9008-916de0527cbf"
+number: 108
+title: "Ajouter la possibilité de joindre des fichiers aux tickets"
+status: "closed"
+priority: "medium"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"user"}
+createdAt: 1785311525586
+updatedAt: 1785328001206
+version: 3
+---
+J'aimerais pouvoir ajouter des fichiers (photo, texte, xml etc...) lisible par les agents AI a mes tickets. Dans le cas ou un fichier a déjà été traité par un agent, il faudrait que le fichier soit résumé dans le carnet et flag par les agents de façon a ce que si plusieurs agents lisent le même tickets, ils ne grillent pas tous leurs tokens a lire le fichier

.ideai/tickets/109/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#109"
+version: 4
+updatedBy: {"kind":"user"}
+updatedAt: 1785328001167
+---

.ideai/tickets/109/issue.md

@@ -0,0 +1,17 @@
+---
+id: "1c6440f1-806f-41e4-92c9-6cef30d3023e"
+number: 109
+title: "Ajouter le nom du créateur de ticket"
+status: "closed"
+priority: "medium"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"user"}
+createdAt: 1785311822279
+updatedAt: 1785328001167
+version: 4
+---
+J'aiemrais que le nom de celui qui a créé le ticket soit ajouté au ticket (nom de l'agent agent ou utilisateur). et qu'un filtre soit ajouté dans la liste des tickets

.ideai/tickets/112/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#112"
+version: 4
+updatedBy: {"kind":"user"}
+updatedAt: 1785341341049
+---

.ideai/tickets/112/issue.md

@@ -0,0 +1,17 @@
+---
+id: "ff8e11d1-98f8-4c6c-b5d0-a8a087c1dbbc"
+number: 112
+title: "Pouvoir ajouter plusieurs tickets a la fois a un sprint"
+status: "closed"
+priority: "medium"
+sprint: null
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"user"}
+createdAt: 1785332192429
+updatedAt: 1785341341049
+version: 4
+---
+Je veux qu'on ajoute la possibilité de set le sprint des tickets selectionnés grace a la selection multiple de ticket dans la liste des tickets.

.ideai/tickets/113/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#113"
+version: 5
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1785748044140
+---

.ideai/tickets/113/issue.md

@@ -0,0 +1,17 @@
+---
+id: "1c128e50-96bd-4689-a080-f6b5e0c5a6b6"
+number: 113
+title: "[Bug] Les espaces ne epuvent pas etre entrés dans les args du serveur llamacpp"
+status: "closed"
+priority: "medium"
+sprint: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1785395710201
+updatedAt: 1785748044140
+version: 5
+---
+Dnas les option de reglage llama.cpp de l'edition des serveurs locaux de modele llm, je ne peux pas entrer d'espaces dans le champs de texte Arguments supplémentaires. Il faut faire en sorte que ça soit possible

.ideai/tickets/114/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#114"
+version: 5
+updatedBy: {"kind":"user"}
+updatedAt: 1785509526119
+---

.ideai/tickets/114/issue.md

@@ -0,0 +1,17 @@
+---
+id: "a7602792-21c6-40f3-852a-5200d604db9d"
+number: 114
+title: "[UI] un iformiser les droplist"
+status: "closed"
+priority: "medium"
+sprint: "5afd6780-0f76-40d7-a10f-32ee52469d74"
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"user"}
+createdAt: 1785395791597
+updatedAt: 1785509526119
+version: 5
+---
+Dans les différentes fenetres j'aimerais qu'on uniformise les droplist. C'est a dire que par exemple dans la fenetre de création de ticket, on a une droplist noire pour la selection d'un agent à lier, j'aimerais que ça soit la même droplist pour la selection du modele dans la fenetre des agents, dans la selection du template a la création d'un agent etc. Que toutes ces petites droplist dynamiques soient comme celle de selection de l'agent dans la fenetre de creation de tickets

.ideai/tickets/115/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#115"
+version: 3
+updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
+updatedAt: 1785499018589
+---

.ideai/tickets/115/issue.md

@@ -0,0 +1,44 @@
+---
+id: "e5db2ff6-64c6-4aaa-a070-67f6904bd7eb"
+number: 115
+title: "Rendre visibles les skills IdeA assignés dans le contexte effectif de chaque agent"
+status: "closed"
+priority: "high"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
+createdAt: 1785497413891
+updatedAt: 1785499018589
+version: 3
+---
+Constat: les agents n'utilisent pas les skills IdeA parce qu'ils n'ont pas connaissance, au runtime, de la liste des skills qu'IdeA leur met à disposition.
+
+Objectif:
+Faire en sorte que, quel que soit l'agent/profil, la liste des skills IdeA assignés soit correctement visible et exploitable par le modèle.
+
+Attendu produit/architecture:
+- La liste des skills assignés doit être traitée comme un artefact d'orchestration/capability snapshot, pas comme du texte documentaire passif.
+- Source de vérité unique côté orchestrateur: catalogue réel des skills + règles d'assignation par agent.
+- Injection systématique de cette liste dans le contexte effectif/prompt livré au modèle:
+  - au lancement
+  - à la reprise
+  - au handoff/changement de profil
+  - idéalement à chaque reconstruction de contexte/tour
+- Format injecté court, stable, structuré et provider-agnostic, avec version de snapshot/catalogue.
+- Règles injectées explicitement: utiliser un skill listé quand la demande y correspond, lire son détail via idea_skill_read(name=...).
+- Fallback runtime si la liste change: soit mécanisme de refresh orchestrateur, soit endpoint/outillage canonique de relecture de la liste assignée.
+
+Invariants à garantir:
+- ne jamais annoncer un skill non réellement accessible
+- ne jamais omettre un skill réellement assigné
+- aucun agent ne commence un tour sans snapshot de skills cohérent avec l'état orchestrateur
+- comportement homogène quel que soit le provider/profil
+- snapshot versionné et traçable
+
+Critères de validation:
+- pour un agent ayant des skills assignés, la liste apparaît bien dans le contexte effectif vu par le modèle
+- l'agent peut citer/consommer un skill assigné sans connaissance préalable externe
+- un changement d'assignation est reflété sans dérive durable entre orchestrateur et agent

.ideai/tickets/116/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#116"
+version: 2
+updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
+updatedAt: 1785500328024
+---

.ideai/tickets/116/issue.md

@@ -0,0 +1,39 @@
+---
+id: "0a38f0bc-e4c0-4e31-b682-738367463989"
+number: 116
+title: "Installer hello-plugin provoque un écran noir / crash apparent d'IdeA"
+status: "closed"
+priority: "critical"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
+createdAt: 1785499247761
+updatedAt: 1785500328024
+version: 2
+---
+Constat utilisateur au 2026-07-31 : lors de l'installation du plugin de démonstration `hello-plugin`, IdeA affiche encore un écran noir, ce qui laisse supposer un crash du runtime/fenêtre.
+
+Contexte utile déjà observé :
+- des correctifs précédents existent autour de `hello-plugin` et du runtime plugin, notamment :
+  - `fe5fe7c` : `fix(hello-plugin): prévient le crash de l'asset protocol dans le runtime Tauri`
+  - `aa85037` / `c100a03` : isolation des contributions plugin en erreur + durcissement menus
+  - `2c3a46e` / `6270f98` : corrections manifeste/contexte hello-plugin
+- malgré cela, l'installation du plugin déclenche encore un écran noir côté utilisateur.
+
+Objectif :
+Identifier la cause racine exacte du black screen au moment de l'installation/chargement de `hello-plugin`, corriger le défaut, et garantir qu'un plugin défectueux ou mal chargé ne puisse plus faire tomber la fenêtre principale d'IdeA.
+
+Attendu :
+- reproduire le problème sur le flux réel d'installation du plugin
+- localiser la couche fautive (installation, validation, asset protocol, chargement frontend, runtime contributions, rendu UI, Tauri)
+- corriger la cause racine
+- ajouter des tests de non-régression sur le chemin réel concerné
+- si un plugin reste invalide/non chargeable, l'UI doit rester vivante avec un état d'erreur explicite, pas un écran noir
+
+Critères de validation :
+- installation réelle de `hello-plugin` sans écran noir ni crash apparent
+- IdeA reste interactive même si le plugin échoue à se charger
+- tests pertinents verts avec preuve réelle

.ideai/tickets/117/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#117"
+version: 7
+updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
+updatedAt: 1785503128343
+---

.ideai/tickets/117/issue.md

@@ -0,0 +1,51 @@
+---
+id: "66e80f94-780b-4856-806d-ba4b96673630"
+number: 117
+title: "Garantir la synchronie métier de idea_ask_agent malgré les background tasks"
+status: "closed"
+priority: "high"
+sprint: null
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"agent","agent_id":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"}
+createdAt: 1785500280516
+updatedAt: 1785503128343
+version: 7
+---
+Constat : quand un agent `A` délègue une demande à un agent `B` via `idea_ask_agent`, `B` peut lancer une background task puis terminer son tour avant que cette tâche ne finisse. Dans ce cas, `A` peut recevoir une pseudo-réponse terminale trop tôt, alors que le travail réel n'est pas terminé.
+
+Décision produit validée : `idea_ask_agent` doit rester synchrone d'un point de vue métier.
+
+Cela implique :
+- `A` ne doit jamais recevoir comme réponse métier finale un simple "task lancée" si le résultat utile dépend encore d'une background task.
+- si `B` a besoin d'une background task pour produire sa réponse, la délégation `A -> B` reste ouverte.
+- la background task est une étape interne du traitement de `B`, pas une réponse à `A`.
+- à la fin de la task, IdeA réveille `B`, puis `B` rend la vraie réponse finale.
+- `A` reste en attente du rendez-vous logique, même si techniquement le tour initial de `B` s'est terminé.
+
+Objectif :
+Faire en sorte qu'une background task lancée pendant un `idea_ask_agent` soit corrélée au rendez-vous inter-agent en cours, et que ce rendez-vous reste ouvert jusqu'à la réponse finale métier de `B`.
+
+Invariants à garantir :
+- `idea_ask_agent` ne se termine jamais par "task lancée" si le résultat utile dépend encore d'une background task.
+- toute background task lancée pendant une délégation porte la corrélation du rendez-vous source.
+- la complétion de task réveille `B`, pas `A` directement.
+- `B` transforme ensuite le résultat en vraie réponse finale à `A`.
+- la réponse capturée pour `A` n'est émise qu'après clôture logique du travail.
+- reboot, cancel, timeout et échec de task ne doivent pas casser cette corrélation.
+
+Découpage attendu :
+1. Étendre le modèle de corrélation pour rattacher une background task à un rendez-vous délégué.
+2. Introduire un état explicite de rendez-vous du type `WaitingOnBackgroundTask` ou équivalent.
+3. Empêcher la clôture terminale d'un `idea_ask_agent` tant qu'une task corrélée est encore ouverte.
+4. À la complétion, réveiller `B`, injecter le résultat dans son inbox, puis laisser `B` répondre à `A`.
+5. Ajouter les tests de reprise après reboot, timeout, cancel et double complétion.
+
+Critères de validation :
+- `A` délègue à `B`, `B` lance une task longue, `A` n'obtient pas de faux terminal.
+- à la fin de la task, `B` est réveillé et répond finalement à `A`.
+- après redémarrage, la réponse finale revient encore à `A`.
+- échec ou annulation de task produisent une réponse terminale cohérente côté `A`.
+- aucune complétion ne reste orpheline hors du rendez-vous initial.

.ideai/tickets/119/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#119"
+version: 4
+updatedBy: {"kind":"user"}
+updatedAt: 1785881187569
+---

.ideai/tickets/119/issue.md

@@ -0,0 +1,134 @@
+---
+id: "b76431d7-f3a3-438f-ae3f-5648f5eda8ce"
+number: 119
+title: "Refondre le système de skills IdeA en capacités agent découvrables"
+status: "closed"
+priority: "high"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785534242629
+updatedAt: 1785881187569
+version: 4
+---
+## Constat
+
+Le système actuel de skills IdeA est techniquement fonctionnel, mais conceptuellement centré sur l'injection de contenu plutôt que sur l'exposition de capacités agent.
+
+État actuel confirmé dans le code :
+- `Skill` + `SkillRef` avec deux scopes `global` / `project`.
+- assignation des skills sur les agents via le manifeste.
+- résolution au lancement, puis composition du contexte effectif.
+- en mode MCP : bloc `# Skills disponibles` + lazy-load via `idea_skill_read(name)`.
+- en mode non-MCP : dump complet du corps des skills dans le contexte.
+- `idea_list_agents` retourne la forme `Agent` du manifeste, donc seulement des `SkillRef` bruts (`skillId` + `scope`), pas un inventaire de capacités utile à un agent ou à Main.
+
+Le défaut de fond est que le catalogue de skills n'existe pas comme objet métier interrogeable. Il n'existe qu'au moment du rendu markdown dans `compose_convention_file`. Le système se comporte donc comme un mécanisme d'injection de documentation, puis simule partiellement une surface de capacités en mode MCP.
+
+## Problèmes à résoudre
+
+1. Les skills assignés ne sont pas modélisés comme un inventaire de capacités agent de premier ordre.
+2. `idea_list_agents` ne permet pas de savoir ce que les autres agents savent faire, seulement quels `SkillRef` opaques leur sont assignés.
+3. L'asymétrie MCP / non-MCP est un patch : mode MCP = affordances bornées, mode non-MCP = dump lourd.
+4. Le système ne distingue pas explicitement un skill procédural (`workflow`) d'un skill de référence (`reference`).
+5. Le modèle actuel n'est pas pleinement aligné avec la frontière produit déjà actée : surface AGENT bornée/distillée/pointeur ; surface HUMAINE riche.
+
+## Cible produit / architecture
+
+Faire évoluer les skills IdeA d'un modèle "contenu injecté" vers un modèle "capacités agent assignées et découvrables".
+
+### Décisions cibles
+
+- Garder :
+  - l'entité `Skill`.
+  - les scopes `global` / `project`.
+  - `SkillRef` dans le manifeste agent.
+  - `idea_skill_read(name)` comme primitive de lazy-load autorisée uniquement sur les skills assignés au requester.
+
+- Ajouter :
+  - une nature explicite de skill, par exemple `SkillKind` avec au minimum :
+    - `Workflow` : procédure exécutable à la demande.
+    - `Reference` : savoir consultable, plus proche d'un contexte sélectif.
+
+- Extraire un use case applicatif réutilisable, type :
+  - `ResolveAgentCapabilities(agent) -> [{ name, description, kind }]`
+
+Ce use case devient la source de vérité commune pour :
+- le bloc `# Skills disponibles` injecté dans le contexte agent.
+- l'exposition des capacités d'un agent dans les surfaces de découverte.
+
+### Arbitrages
+
+- Ne pas créer de `idea_list_skills` global.
+  - Les skills ne sont pas des tools MCP uniformes de session.
+  - Ce sont des capacités portées par un agent.
+  - La bonne surface de découverte inter-agent est donc `idea_list_agents` enrichi, pas un catalogue global détaché des porteurs.
+
+- Enrichir `idea_list_agents` avec un champ additif du type :
+  - `capabilities: [{ name, description, kind }]`
+
+- Supprimer à terme le dump complet des corps de skills en mode non-MCP.
+  - Le remplacer par une surface bornée et homogène avec le mode MCP : catalogue compact + lecture à la demande via la surface adaptée au runtime.
+
+- Distinguer la politique d'injection selon le type :
+  - `Workflow` : jamais injecté en corps complet par défaut.
+  - `Reference` : peut éventuellement être injecté de façon compacte selon des règles bornées (optionnel, à arbitrer plus tard).
+
+## Frontières avec les autres surfaces IdeA
+
+- Tools MCP :
+  - les skills ne deviennent pas des tools MCP.
+  - `idea_skill_read` reste un pont vers les skills, pas une matérialisation des skills comme tools.
+
+- Contexte projet :
+  - le contexte reste global au projet et commun.
+  - un skill reste assignable sélectivement agent par agent.
+
+- Mémoire durable :
+  - la mémoire reste un savoir stabilisé écrit dynamiquement.
+  - un skill reste une capacité/version de workflow éditée explicitement.
+
+- Live-state :
+  - aucun recouvrement fonctionnel ; pas de mélange.
+
+- Templates :
+  - à envisager plus tard : un template pourrait référencer des skills à assigner par défaut.
+  - en revanche, un template ne doit pas dupliquer le corps des skills.
+
+- Plugins :
+  - hors périmètre ; ne pas confondre extension IDE humaine et capacité agent.
+
+## Plan de migration incrémental
+
+1. **Domaine**
+   - ajouter `SkillKind` sur `Skill` avec rétrocompatibilité (`default`).
+
+2. **Application**
+   - extraire un use case dédié de résolution des capacités agent à partir des `SkillRef` assignés.
+
+3. **Surfaces agent / orchestration**
+   - faire reposer `# Skills disponibles` sur ce use case au lieu de recalculer localement pendant le rendu markdown.
+
+4. **Découverte inter-agent**
+   - enrichir `idea_list_agents` avec les capacités résolues de chaque agent, en gardant les `skills` bruts si nécessaire pour compatibilité.
+
+5. **Unification MCP / non-MCP**
+   - supprimer le dump intégral non-MCP et le remplacer par une surface bornée cohérente avec le modèle capability-first.
+
+6. **Optionnel ensuite**
+   - politique fine d'injection compacte pour certains skills `Reference` courts.
+
+## Critères de succès
+
+- Un agent neuf connaît immédiatement ses skills assignés sous forme d'affordances bornées, sans dépendre d'un dump lourd.
+- Un agent ou Main peut découvrir les capacités utiles d'un autre agent sans manipuler des `SkillRef` opaques.
+- Le système reste cohérent avec la séparation IdeA : surface agent bornée, surface humaine riche.
+- Le modèle fonctionne proprement en MCP et hors MCP, sans dégradation conceptuelle majeure.
+- `idea_skill_read` reste la primitive de lecture détaillée et d'autorisation.
+
+## Notes
+
+Ce ticket est un ticket de refonte/cadrage cible. Il ne demande pas de refaire le stockage ni de supprimer `idea_skill_read`. La refonte porte sur le modèle de capacité agent, la composition de contexte et les surfaces de découverte.

.ideai/tickets/120/carnet.md

@@ -0,0 +1,264 @@
+---
+issueRef: "#120"
+version: 11
+updatedBy: {"kind":"user"}
+updatedAt: 1785881187579
+---
+---
+issueRef: "#120"
+version: 8
+updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedAt: 1785595113109
+---
+# Carnet de suivi — hello-plugin
+
+## Etat courant
+
+- Ticket canonique: `#120`
+- Ticket parent historique: `#43`
+- Date de rechute confirmee: 2026-08-01
+- Statut: investigation relancee sur rechute reelle post-rebuild SDK
+- Severite: critique (l'UI d'IdeA tombe sur une erreur d'affichage lors de l'installation/chargement de `hello-plugin`)
+
+## Constat central au 2026-08-01
+
+Le probleme persiste meme apres reconstruction de `hello-plugin` comme plugin d'exemple 100% SDK.
+
+Implication forte:
+- la cause racine est probablement dans le systeme plugin / runtime frontend / chargement UI / integration layout-menu, et non dans l'ancien exemple `hello-plugin` uniquement.
+
+## Trace utilisateur fournie le 2026-08-01
+
+Message visible:
+- `IdeA a rencontre une erreur d'affichage.`
+- `L'application reste ouverte. Rechargez la fenetre apres avoir copie le diagnostic si le probleme doit etre investigue.`
+
+Stack affichee (trace la plus recente):
+
+```text
+ST@tauri://localhost/assets/index-DxqF_K_z.js:88:33125
+wT@tauri://localhost/assets/index-DxqF_K_z.js:88:32065
+om@tauri://localhost/assets/index-DxqF_K_z.js:38:17019
+oh@tauri://localhost/assets/index-DxqF_K_z.js:40:3141
+Fb@tauri://localhost/assets/index-DxqF_K_z.js:40:39779
+SC@tauri://localhost/assets/index-DxqF_K_z.js:40:39707
+ic@tauri://localhost/assets/index-DxqF_K_z.js:40:39559
+yh@tauri://localhost/assets/index-DxqF_K_z.js:40:35923
+Bb@tauri://localhost/assets/index-DxqF_K_z.js:40:34872
+E@tauri://localhost/assets/index-DxqF_K_z.js:25:1541
+L@tauri://localhost/assets/index-DxqF_K_z.js:25:1903
+
+wT@tauri://localhost/assets/index-DxqF_K_z.js:88:28284
+div
+div
+div
+MD@tauri://localhost/assets/index-DxqF_K_z.js:94:63541
+main
+div
+div
+G4@tauri://localhost/assets/index-DxqF_K_z.js:129:18726
+div
+div
+yT@tauri://localhost/assets/index-DxqF_K_z.js:88:24863
+BP@tauri://localhost/assets/index-DxqF_K_z.js:88:1862
+ez@tauri://localhost/assets/index-DxqF_K_z.js:129:31967
+mP@tauri://localhost/assets/index-DxqF_K_z.js:82:27658
+Iz@tauri://localhost/assets/index-DxqF_K_z.js:129:83720
+```
+
+## Faits etablis avant cette rechute
+
+- Un rebuild SDK de `hello-plugin` a ete realise pour produire un plugin d'exemple minimal mais fonctionnel.
+- Des verifications de build, packaging et tests locaux ont ete annoncees vertes par DevFrontend.
+- QA avait pu valider partiellement:
+  - l'artefact SDK se reconstruit
+  - le plugin s'installe cote runtime/backend
+  - IdeA charge reellement le bundle plugin via `idea-plugin://.../dist/index.js`
+- QA n'avait pas pu valider de bout en bout la surface UI visible (menu `Hello Plugin`, entree `hello-plugin`, rendu `hello-world`) faute d'une session UI observable sans ambiguite.
+
+## Reinterpretation apres rechute utilisateur
+
+- L'absence de validation UI de bout en bout n'etait pas un detail: la rechute utilisateur montre que le crash survient bien dans le flux reel d'affichage, malgre un plugin reconstruit proprement.
+- Le signal pointe desormais plus fortement vers un probleme dans la consommation frontend des contributions plugin que vers le contenu fonctionnel du plugin lui-meme.
+
+## Cadrage UX du 2026-08-01
+
+- Une contribution plugin invalide ou qui plante ne doit jamais faire tomber l'app entiere.
+- Le fallback attendu est local a la surface plugin en faute:
+  - menu plugin en erreur -> menus natifs seuls
+  - layout plugin en erreur -> fallback local de layout indisponible
+- `INTERFACE INTERROMPUE` doit rester reserve aux crashs shell irrecoverables.
+- A terme, l'etat d'erreur plugin devrait rester visible dans la gestion des plugins plutot qu'etre seulement silencieux.
+
+## Requalification Architect du 2026-08-01
+
+- Fait cle: le meme hash de crash apparait avec deux plugins differents:
+  - ancien hello-plugin minimal (menu + item, sans layout utile)
+  - nouveau hello-plugin reconstruit via SDK (menu + item + layout)
+- Denominateur commun probable: la contribution de menu, pas le layout.
+- Zone la plus suspecte identifiee: `ProjectsView.tsx` sur l'injection de `pluginMenus` dans `<MenuBar>`.
+- Point precis: le rendu des menus plugin est consomme dans l'app-shell sans isolation locale equivalente a celle deja ajoutee pour `PluginLayoutCellView`.
+- Hypothese prioritaire: une entree de menu plugin ou son rendu dans `MenuBar` leve une erreur qui remonte jusqu'a `RootErrorBoundary`, produisant `INTERFACE INTERROMPUE`.
+- Strate touchee: frontend prioritaire, pas de nouveau chantier backend requis pour cette cause racine.
+
+## Verification DevFrontend du 2026-08-01
+
+- Branche verifiee: `feature/ticket120-plugin-menu-crash-isolation`
+- HEAD verifie: `5a30ec8`
+- Verdict DevFrontend: le correctif existant couvre deja la rechute prioritaire sur le chemin `ProjectsView -> usePluginMenus -> MenuBar`.
+- Aucun complement de code ajoute a ce stade.
+- Verifications executees:
+  - `cd frontend && npx vitest run src/features/plugins/usePluginMenus.test.tsx src/plugins/runtime/loader.test.ts src/features/plugins/menus.test.ts` : OK (22 tests)
+  - `cd frontend && npx vitest run` : OK (114 fichiers, 1046 tests)
+
+## Correctif systeme plugin/UI deja porte par la branche
+
+### Cause probable retenue
+Deux plugins differents declenchent le meme crash minifie apres installation. Le denominateur commun le plus probable est le chemin `ProjectsView -> usePluginMenus -> MenuBar`.
+
+### Correctif applique
+- `usePluginMenus` isole defensivement la resolution/conversion des contributions plugin.
+- Si la resolution de menus ou d'items plugin throw, le hook renvoie `[]` pour la surface plugin concernee au lieu de propager l'erreur.
+- `ProjectsView` separe les menus natifs des menus enrichis par plugin.
+- `ProjectsView` rend `MenuBar` derriere une error boundary locale: si le rendu enrichi plante, fallback immediat sur les menus natifs seuls.
+- Logs ajoutes:
+  - `[plugins] menu contribution rejected` avec le contexte utile quand disponible
+  - `[plugins] menu render failed; using native menus only`
+
+### Fichiers touches
+- `frontend/src/features/plugins/usePluginMenus.ts`
+- `frontend/src/features/plugins/usePluginMenus.test.tsx`
+- `frontend/src/features/projects/ProjectsView.tsx`
+
+## Validation QA du 2026-08-01
+
+- Branche validee: `feature/ticket120-plugin-menu-crash-isolation`
+- HEAD valide: `5a30ec8b9c4758602cc96e72ffd69e415422cd85`
+- Verdict QA courant: bug `INTERFACE INTERROMPUE` non reproduit par les validations reelles executees ici.
+
+### Commandes executees
+- `git -C /home/anthony/Documents/Projects/IdeA rev-parse HEAD`
+- `npm --prefix /home/anthony/Documents/Projects/IdeA/sdk/IdeaSDK run package:hello-plugin`
+- `cd /home/anthony/Documents/Projects/IdeA/frontend && npx vitest run src/features/plugins/menus.test.ts src/features/plugins/usePluginMenus.test.tsx src/features/plugins/plugins.test.tsx src/plugins/runtime/loader.test.ts`
+- `cargo test -p infrastructure --test plugin_install_load -- --nocapture`
+- `cargo test -p infrastructure extracts_archive_without_path_escape -- --nocapture`
+- `cd /home/anthony/Documents/Projects/IdeA/frontend && npm run test:bundle-transport`
+- `cd /home/anthony/Documents/Projects/IdeA/crates/app-tauri && NO_STRIP=true ../../frontend/node_modules/.bin/tauri build --bundles appimage`
+
+### Resultats utiles
+- archive SDK regeneree: `sdk/IdeaSDK/examples/hello-plugin/build/hello-plugin-0.1.0.zip`
+- tests frontend cibles: OK (4 fichiers, 29 tests)
+- tests backend d'installation/chargement plugin: OK (3 tests)
+- AppImage rebuild: `target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`
+
+### Limite de preuve restante
+- Pas de harness e2e UI automatise ici pour cliquer le parcours Tauri/AppImage "Installer depuis une archive..." de bout en bout.
+- La validation est donc reelle sur archive SDK, backend d'installation, non-regression frontend, et artefact packagé reconstruit, mais pas sur un clic UI automatise observable.
+
+## Requalification Architect du 2026-08-01 (rechute post-rebuild)
+
+### Fait determinant trouve par inspection directe des artefacts
+
+Deux binaires AppImage distincts coexistent sur la machine, avec un ecart temporel et de contenu net:
+
+| Fichier | mtime | sha256 (8 premiers car.) |
+|---|---|---|
+| `/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage` (celui qu'IdeA fait tourner — cf. memoire `mcp-bridge-and-delegation-runtime-notes`) | 2026-07-24 15:09 | `61d499f2` |
+| `target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage` (rebuild QA du jour) | 2026-08-01 16:37 | `9ad50c21` |
+
+Le commit du correctif (`5a30ec8`, isolation `usePluginMenus`/`ProjectsView`) date du **2026-08-01 16:23:56**, soit **apres** le mtime du binaire `~/Documents`. Le binaire que l'utilisateur execute au quotidien (`~/Documents/IdeA_0.3.0_amd64.AppImage`) est donc anterieur de plusieurs jours au correctif et ne peut structurellement pas le contenir.
+
+### Requalification de cause racine
+
+- La rechute rapportee le 2026-08-01 par l'utilisateur est tres vraisemblablement un **artefact de deploiement**, pas une regression de code: le rebuild QA a produit un binaire correct dans `target/release/bundle/appimage/`, mais ce binaire n'a jamais remplace celui reellement lance par l'utilisateur (`~/Documents/IdeA_0.3.0_amd64.AppImage`).
+- C'est exactement le piege deja documente en memoire projet (`mcp-bridge-and-delegation-runtime-notes`, section « Le binaire qui tourne = AppImage installee, pas les sources ») applique cette fois au correctif plugin plutot qu'au pont MCP.
+- Le carnet QA ci-dessus ne mentionne a aucun moment le remplacement du binaire `~/Documents` ni le redemarrage d'IdeA sur ce binaire remplace — seule la production de l'artefact dans `target/release/bundle/` est tracee.
+
+### Borne de correction attendue
+
+- **Aucun nouveau code frontend ou backend n'est requis a ce stade.** Le correctif `5a30ec8` (isolation menus plugin) est deja en place et deja valide par tests reels (114 fichiers / 1046 tests vitest, tests backend d'installation/chargement).
+- Action requise: deploiement, pas developpement — remplacer `~/Documents/IdeA_0.3.0_amd64.AppImage` par `target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage` (backup de l'ancien conseille, cf. convention memoire `*.old-<raison>fix`), relancer IdeA depuis ce binaire, puis reproduire exactement le parcours Parametres > Plugins > Installer depuis une archive > hello-plugin.
+- Si la rechute persiste APRES ce remplacement effectif et un redemarrage complet d'IdeA, alors l'hypothese frontend doit etre rouverte avec un perimetre elargi au-dela de `ProjectsView -> usePluginMenus -> MenuBar`, en verifiant en priorite (deja inspectes le 2026-08-01, RAS a la lecture statique mais non exerces en e2e reel):
+  - `frontend/src/features/plugins/PluginsPanel.tsx` (flux `startInstallFromArchive` / `reviewArchive` / dialog de confirmation) — surface active au moment precis du clic « Installer »
+  - `frontend/src/features/plugins/PluginConfirmDialog.tsx`
+  - `frontend/src/features/plugins/PluginLayoutCellView.tsx` (isolation deja posee en amont de ce ticket, a re-verifier qu'elle couvre bien le layout du hello-plugin reconstruit)
+  - la place de `RootErrorBoundary` par rapport a ces surfaces, pour confirmer qu'aucun chemin ne la contourne
+
+### Prochaine etape (remplace la precedente)
+
+- Ne pas rouvrir de chantier de code avant d'avoir confirme que l'utilisateur reproduit sur le binaire effectivement a jour.
+- Remplacement de binaire + retest = action Git/deploiement, a executer avant toute nouvelle investigation frontend.
+
+## Requalification Architect du 2026-08-01 (nouveau symptome CORS apres installation)
+
+### Nouveau fait utilisateur
+
+Le symptome visible n'est plus seulement un ecran noir: dans la vue Plugins, IdeA affiche apres installation de `hello-plugin` un bandeau explicite:
+- `Certains plugins installes n'ont pas pu etre charges.`
+- `com.example.hello-plugin : Cross-origin script load denied by Cross-Origin Resource Sharing policy.`
+
+Cette observation invalide la piste `LayoutTabs -> PluginLayoutSelectorSection` comme cause racine de ce symptome precis. Le durcissement frontend precedent reste utile: il a empeche le black screen et laisse remonter l'erreur exploitable.
+
+### Cause racine retenue
+
+- Le protocole custom `idea-plugin://` repondait sans headers CORS dans `crates/app-tauri/src/plugins.rs` (`plugin_asset_response`).
+- Le frontend charge le bundle plugin via `import()` dynamique depuis `frontend/src/plugins/runtime/loader.ts`; ce chargement est un fetch CORS.
+- L'origine du document (`tauri://localhost` / `http://tauri.localhost` en prod, `http://localhost:5173` en dev) est distincte de `idea-plugin://...`.
+- Faute de `Access-Control-Allow-Origin`, WebKitGTK bloque le module avec exactement le message observe.
+
+### Couche proprietaire et perimetre de correction
+
+- Couche proprietaire: backend/infrastructure `app-tauri`, pas frontend produit, pas packaging plugin.
+- Correctif attendu:
+  - ajouter `Access-Control-Allow-Origin` sur les reponses du protocole plugin
+  - ajouter `Access-Control-Allow-Methods: GET`
+  - conserver intact le confinement `asset_allowed`
+  - ajouter un test backend verrouillant ces headers sur `plugin_asset_response`
+
+## Livraison DevBackend du 2026-08-01
+
+- Branche de travail dediee: `feature/ticket120-plugin-asset-cors-headers`
+- Correctif implemente dans `crates/app-tauri/src/plugins.rs`
+- Headers ajoutes sur les reponses du protocole `idea-plugin://`:
+  - `Access-Control-Allow-Origin: *`
+  - `Access-Control-Allow-Methods: GET`
+- Factorisation via un builder de reponse commun aux chemins succes/erreur du protocole
+- Test ajoute: `plugin_asset_response_includes_cors_headers_for_dynamic_import`
+
+### Commandes executees par DevBackend
+- `cargo fmt -p app-tauri` : OK
+- `cargo test -p app-tauri plugin_asset_response_includes_cors_headers_for_dynamic_import` : OK
+- `cargo test -p app-tauri plugins::tests` : OK
+- `cargo test -p app-tauri` : OK (242 passed, 0 failed, 5 ignored)
+
+## Validation QA du 2026-08-01 (fix CORS)
+
+### Verdict
+- PASS avec reserve explicite.
+
+### Validation reelle obtenue
+- `cargo test -p app-tauri plugin_asset_response_includes_cors_headers_for_dynamic_import -- --nocapture` : OK
+- `cargo test -p app-tauri` : OK
+- `cargo test -p infrastructure --test plugin_install_load installs_sdk_hello_plugin_and_loads_runtime_catalog -- --nocapture` : OK
+- `cargo test -p infrastructure --test plugin_install_load installs_reference_fixture_and_loads_runtime_catalog -- --nocapture` : OK
+- `npm --prefix /home/anthony/Documents/Projects/IdeA/sdk/IdeaSDK run package:hello-plugin` : OK
+- `cd /home/anthony/Documents/Projects/IdeA/frontend && npx vitest run src/plugins/runtime/loader.test.ts src/features/plugins/plugins.test.tsx src/features/plugins/menus.test.ts` : OK (27 tests)
+
+### Reserve QA restante
+- Pas de preuve visuelle AppImage/UI de bout en bout dans cet environnement.
+- Tentative de build AppImage realisee, mais l'artefact final n'etait pas disponible ensuite dans `target/release/bundle/appimage/`.
+- Tentative d'execution d'une AppImage existante bloquee par l'environnement (`No suitable fusermount binary found on the $PATH`).
+- Risque residuel exact: le fix est prouve au niveau handler backend, catalogue runtime et chargeur frontend, mais pas sur l'enchainement visuel complet `archive installee -> redemarrage UI reel -> absence du bandeau CORS`.
+
+## Decision Git du 2026-08-01
+
+- Commit local realise sur la branche dediee: `fbe69de`
+- Merge local `--no-ff` dans `develop`: `fd2ab4a`
+- Motivation: QA a rendu un verdict PASS; la reserve porte sur une limite d'environnement de preuve AppImage/FUSE, pas sur un test rouge.
+- La branche `feature/ticket120-plugin-asset-cors-headers` a ete supprimee apres merge.
+
+## Etat reel a la fin de cette relance
+
+- Le correctif CORS est livre dans `develop`.
+- Le ticket **reste a considerer ouvert fonctionnellement** tant qu'une validation visuelle reelle sur AppImage/redemarrage n'a pas confirme la disparition du bandeau `Cross-origin script load denied by Cross-Origin Resource Sharing policy` et l'activation effective des contributions `hello-plugin`.
+- Prochaine preuve attendue hors environnement QA courant: lancer le binaire AppImage reellement utilise par l'utilisateur, installer l'archive `hello-plugin`, redemarrer IdeA, verifier visuellement l'absence du bandeau CORS et la presence des contributions plugin actives.

.ideai/tickets/120/issue.md

@@ -0,0 +1,34 @@
+---
+id: "f4218553-680a-4fbb-9514-a96eab79b8d8"
+number: 120
+title: "Réinvestiguer l’installation de hello-plugin: écran noir / perte d’affichage IdeA"
+status: "closed"
+priority: "critical"
+sprint: null
+links: [{"target":"#116","kind":"relatesTo"},{"target":"#43","kind":"relatesTo"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785534496259
+updatedAt: 1785881187579
+version: 11
+---
+## Constat utilisateur
+
+Au 2026-07-31, l’installation de `hello-plugin` fait encore perdre tout l’affichage d’IdeA (écran noir / UI vide), malgré un précédent correctif supposé sur `#116`.
+
+## Objectif
+
+Reprendre le sujet proprement avec un ticket neuf de réinvestigation et de durcissement:
+- recréer un plugin de test minimal `hello-plugin` depuis zéro pour repartir d’un cas maîtrisé ;
+- renforcer les tests e2e autour du cycle d’installation plugin ;
+- identifier précisément la cause réelle de la perte d’affichage ;
+- corriger le ou les défauts (backend, frontend, runtime, permissions, flux d’installation, etc.) ;
+- valider la non-régression sur le cas `hello-plugin`.
+
+## Notes de cadrage
+
+- Le ticket n’assume pas que la cause soit dans le plugin lui-même ; la reconstruction du plugin sert de témoin minimal reproductible.
+- Le ticket doit s’appuyer sur le précédent `#116` mais repart d’un constat live utilisateur indiquant que le système plugin reste non fiable.
+- La sortie attendue inclut des tests e2e réellement exécutés et un rebuild AppImage pour validation dans le binaire utilisé par IdeA.

.ideai/tickets/121/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#121"
+version: 2
+updatedBy: {"kind":"agent","agent_id":"dce19c75-9669-4e45-b8de-9950025157da"}
+updatedAt: 1785534534027
+---

.ideai/tickets/121/issue.md

@@ -0,0 +1,16 @@
+---
+id: "07d83a8e-63cd-4f72-b056-aaf792d517fb"
+number: 121
+title: "__probe__"
+status: "closed"
+priority: "medium"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"dce19c75-9669-4e45-b8de-9950025157da"}
+updatedBy: {"kind":"agent","agent_id":"dce19c75-9669-4e45-b8de-9950025157da"}
+createdAt: 1785534526705
+updatedAt: 1785534534027
+version: 2
+---

.ideai/tickets/122/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#122"
+version: 4
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1785748044193
+---

.ideai/tickets/122/issue.md

@@ -0,0 +1,17 @@
+---
+id: "fa083793-48ae-417a-ab16-3813e22df2e3"
+number: 122
+title: "[Bug] Override des permissions defaut qui ne marche pas"
+status: "closed"
+priority: "medium"
+sprint: null
+links: []
+agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
+attachments: []
+createdBy: {"kind":"user"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1785592422173
+updatedAt: 1785748044193
+version: 4
+---
+J'ai l'impression que l'override des permissions systeme ne fonctionne pas. J'avais les permissions par defaut qui ne donnait pas les droits bash, et meme après avoir override ce parametre sur un de mes agents, il n'avait aps acces aux tools bash. Il y a eu acces une fois qu'avais mis le droit dans la config defaut

.ideai/tickets/123/carnet.md

@@ -0,0 +1,39 @@
+---
+issueRef: "#123"
+version: 5
+updatedBy: {"kind":"user"}
+updatedAt: 1785881187586
+---
+## Contexte
+Le besoin initial vient d’un futur plugin orienté développement Android, mais le périmètre validé pour ce chantier est strictement **SDK générique**. L’objectif n’est pas d’ajouter des API Android-first, mais de combler les trous du SDK public qui empêchent aujourd’hui tout plugin de développement un peu sérieux.
+
+## Ce qui existe déjà
+- Manifest public `idea-plugin.json`
+- Runtime `activate(ctx)`
+- `commands`, `storage`, `logger`
+- `services.workspace`, `services.tasks`, `services.terminal`
+- Contributions `menus`, `menuItems`, `layouts`, `mcpServers`
+
+## Problème
+Le SDK public actuel est volontairement minimal. Il permet des plugins simples, mais pas un plugin d’outillage qui doit agir sur un workspace, lancer des outils externes, réagir aux événements du host, afficher une UI riche, ou analyser la structure d’un projet.
+
+## Décision de cadrage
+Découper le besoin en tickets transverses, indépendants autant que possible.
+
+Ordre de priorité retenu :
+1. `#124` API fichiers/workspace
+2. `#125` API lancement de commandes et tâches
+3. `#126` API découverte/validation d’outillage externe
+4. `#127` API d’événements et de watch
+5. `#128` runtime UI/layout publique
+6. `#129` API d’analyse/requête de structure projet
+7. `#130` API de documents de configuration structurés
+
+## Garde-fous
+- Pas d’API spécifique Android dans ce lot.
+- Préserver une frontière SDK public vs runtime interne.
+- Favoriser des primitives génériques réutilisables pour Android, iOS, Node, Python, Docker, etc.
+- Éviter de forcer les plugins à dépendre de casts ad hoc ou d’objets runtime internes.
+
+## Définition de done du parapluie
+Le parapluie est clôturable quand les tickets enfants retenus pour le MVP sont livrés ou explicitement re-scopeés avec arbitrage.

.ideai/tickets/123/issue.md

@@ -0,0 +1,17 @@
+---
+id: "0013caf7-bbc9-439f-82b2-9d23ed9e901a"
+number: 123
+title: "SDK plugins: combler les capacités globales manquantes pour les plugins de développement outillés"
+status: "closed"
+priority: "high"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785662012603
+updatedAt: 1785881187586
+version: 5
+---
+Ticket parapluie pour structurer l’extension du SDK public des plugins IdeA afin de supporter des plugins de développement avancés sans introduire d’API métier spécifiques à une stack donnée. Le besoin initial vient du cas Android, mais le périmètre doit rester strictement transversal.

.ideai/tickets/124/carnet.md

@@ -0,0 +1,39 @@
+---
+issueRef: "#124"
+version: 5
+updatedBy: {"kind":"user"}
+updatedAt: 1785881187593
+---
+## Problème
+`WorkspaceService` public expose aujourd’hui seulement le projet courant, son root, et la lecture/écriture du contexte Markdown IdeA. Cela ne suffit pas pour un plugin de développement qui doit lire, écrire, lister ou surveiller les fichiers d’un projet.
+
+## Pourquoi c’est global
+Ce besoin n’a rien de spécifique à Android. Tout plugin de dev outillé doit pouvoir manipuler le workspace : configs, manifests, scripts, sources, fichiers générés, assets, etc.
+
+## Ce que ce ticket doit produire
+Une API publique de workspace/fichiers permettant au minimum :
+- lecture de fichier texte/binaire
+- écriture atomique ou contrôlée
+- listing de répertoires
+- existence/stat basiques
+- résolution sûre de chemins dans le project root
+- capacité de watch ou point d’extension compatible avec `#127`
+
+## Contraintes d’architecture
+- API strictement publique côté SDK TypeScript.
+- Aucun accès direct aux objets runtime internes.
+- Respect du sandboxing et du project root.
+- Contrat clair sur les erreurs, encodages, chemins hors-root et fichiers absents.
+
+## Non-objectifs
+- Pas de parser Gradle/XML/JSON dans ce ticket.
+- Pas d’analyse sémantique du projet.
+- Pas de conventions Android codées en dur.
+
+## Dépendances
+- Bloque `#126`, `#129`, `#130`.
+
+## Critères d’acceptation
+- Un plugin peut lire/écrire/lister dans le workspace sans cast interne.
+- Le contrat gère explicitement les chemins invalides/hors-root.
+- La documentation SDK montre un exemple simple de manipulation de fichiers.

.ideai/tickets/124/issue.md

@@ -0,0 +1,17 @@
+---
+id: "639787e1-83b5-49b7-a89f-3a6985129163"
+number: 124
+title: "SDK plugins: exposer une API publique d’accès fichiers/workspace"
+status: "closed"
+priority: "critical"
+sprint: null
+links: [{"target":"#123","kind":"blocks"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785662026640
+updatedAt: 1785881187593
+version: 5
+---
+Ajouter au SDK plugin une API publique de lecture/écriture/listing/watch dans le workspace projet, distincte du simple accès au contexte Markdown IdeA.

.ideai/tickets/125/carnet.md

@@ -0,0 +1,40 @@
+---
+issueRef: "#125"
+version: 5
+updatedBy: {"kind":"user"}
+updatedAt: 1785881187607
+---
+## Problème
+Le SDK public permet seulement :
+- d’observer/contrôler des background tasks existantes
+- d’ouvrir un PTY interactif
+
+Il manque une API publique pour **démarrer** une commande/outillage externe de façon intégrée à IdeA.
+
+## Pourquoi c’est global
+Le besoin est transversal à tous les plugins de développement : build, test, lint, génération, outils CLI, pipelines locaux, simulateurs, wrappers maison.
+
+## Ce que ce ticket doit produire
+Une API publique de lancement de commandes/tâches permettant au minimum :
+- exécuter une commande avec `cwd`, args, env
+- choisir un mode tracked/background task plutôt qu’un PTY brut
+- suivre statut, exit code, stdout/stderr
+- annuler / éventuellement relancer
+- corréler le run avec le modèle Work d’IdeA
+
+## Contraintes d’architecture
+- Ne pas confondre terminal interactif et task runner.
+- Contrat stable sur environnement, cwd, timeouts éventuels, sortie et erreurs.
+- Le plugin ne doit pas avoir à bricoler une session PTY pour lancer un build.
+
+## Non-objectifs
+- Pas de sémantique Android/Gradle/adb.
+- Pas d’orchestration multi-étapes spécifique à une stack.
+
+## Dépendances
+- Bloque `#126`.
+
+## Critères d’acceptation
+- Un plugin peut lancer une commande externe sans passer par un cast interne ni un PTY interactif.
+- L’exécution remonte un état observable et un résultat terminal clair.
+- Le contrat est documenté côté SDK avec exemple de commande simple.

.ideai/tickets/125/issue.md

@@ -0,0 +1,17 @@
+---
+id: "78bb45fb-6320-4d75-8db2-1e2a9591219f"
+number: 125
+title: "SDK plugins: exposer une API publique de lancement de commandes et tâches"
+status: "closed"
+priority: "critical"
+sprint: null
+links: [{"target":"#123","kind":"blocks"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785662026655
+updatedAt: 1785881187607
+version: 5
+---
+Ajouter au SDK plugin une API publique pour lancer des commandes/outils externes et suivre leur exécution comme tâches IdeA, au-delà de l’observation des tâches existantes et du simple PTY interactif.

.ideai/tickets/126/carnet.md

@@ -0,0 +1,36 @@
+---
+issueRef: "#126"
+version: 8
+updatedBy: {"kind":"user"}
+updatedAt: 1785881187599
+---
+## Problème
+Un plugin de dev a souvent besoin de savoir si un outillage externe existe, où il se trouve, quelle version est installée, et si l’environnement est valide. Le SDK public n’expose pas aujourd’hui cette capacité comme primitive générique.
+
+## Pourquoi c’est global
+Ce besoin vaut pour Android SDK, Java, Node, Python, Docker, Go, Rust toolchain, etc. Le ticket doit fournir une abstraction générique de découverte/validation d’outillage, pas une API dédiée Android.
+
+## Ce que ce ticket doit produire
+Une API publique permettant idéalement :
+- résolution d’un exécutable ou d’une toolchain par nom/id
+- lecture de version
+- inspection de variables d’environnement pertinentes
+- validation de prérequis déclaratifs
+- restitution d’un diagnostic structuré exploitable par une UI plugin
+
+## Contraintes d’architecture
+- La source de vérité peut s’appuyer sur fichiers, env et exécution d’outils, mais l’API exposée doit rester stable et agnostique.
+- Ne pas figer de modèle métier Android.
+
+## Dépendances
+- Dépend de `#124` pour l’accès workspace/config.
+- Dépend de `#125` pour l’exécution contrôlée des commandes de détection.
+
+## Non-objectifs
+- Pas de gestion d’émulateur/device manager.
+- Pas d’installation automatique d’une toolchain dans ce ticket.
+
+## Critères d’acceptation
+- Un plugin peut diagnostiquer la présence/absence d’un outillage externe de façon structurée.
+- Le diagnostic est assez générique pour servir plusieurs stacks.
+- La doc SDK montre un cas simple de détection d’exécutable/version.

.ideai/tickets/126/issue.md

@@ -0,0 +1,17 @@
+---
+id: "51d4f4b0-4482-4400-a0d5-9f88471581f0"
+number: 126
+title: "SDK plugins: exposer une API publique de découverte/validation d’outillage externe"
+status: "closed"
+priority: "high"
+sprint: null
+links: [{"target":"#123","kind":"blocks"},{"target":"#124","kind":"dependsOn"},{"target":"#125","kind":"dependsOn"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785662026684
+updatedAt: 1785881187599
+version: 8
+---
+Ajouter au SDK plugin une API publique pour détecter, valider et décrire des toolchains externes (exécutables, versions, variables d’environnement, prérequis) sans spécialiser le SDK pour une stack donnée.

.ideai/tickets/127/carnet.md

@@ -0,0 +1,35 @@
+---
+issueRef: "#127"
+version: 5
+updatedBy: {"kind":"user"}
+updatedAt: 1785881187615
+---
+## Problème
+Sans bus d’événements ou API de watch publique, un plugin doit poller l’état du host ou du workspace pour se tenir à jour. C’est coûteux, fragile et peu réactif.
+
+## Pourquoi c’est global
+Tout plugin de dev outillé peut avoir besoin de réagir à :
+- changement de fichier
+- fin/échec d’une tâche
+- changement de projet courant
+- autres événements système ou host pertinents
+
+## Ce que ce ticket doit produire
+Une API publique d’abonnement permettant au minimum :
+- souscription/désinscription propre
+- typage minimal des événements publics
+- événements documentés et versionnables
+- stratégie claire sur rétention/perte d’événements
+
+## Contraintes d’architecture
+- Exposer uniquement des événements publics stables.
+- Ne pas refléter brut de décoffrage les événements internes du host.
+- Bien définir les garanties: best effort vs livraison fiable.
+
+## Non-objectifs
+- Pas de protocole temps réel cross-process complexe si non nécessaire.
+- Pas d’événements spécifiques Android.
+
+## Critères d’acceptation
+- Un plugin peut se mettre à jour sur changements du workspace/host sans polling permanent.
+- L’API de subscription est proprement disposable et documentée.

.ideai/tickets/127/issue.md

@@ -0,0 +1,17 @@
+---
+id: "9b238559-9982-4a69-8795-99da8a46be1e"
+number: 127
+title: "SDK plugins: exposer une API publique d’événements et de watch"
+status: "closed"
+priority: "high"
+sprint: null
+links: [{"target":"#123","kind":"blocks"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785662026701
+updatedAt: 1785881187615
+version: 5
+---
+Ajouter au SDK plugin une API publique d’abonnement aux événements utiles du host et du projet: changements de fichiers, évolution des tâches, focus projet et autres signaux nécessaires pour éviter le polling côté plugin.

.ideai/tickets/128/carnet.md

@@ -0,0 +1,31 @@
+---
+issueRef: "#128"
+version: 5
+updatedBy: {"kind":"user"}
+updatedAt: 1785881187622
+---
+## Problème
+Le manifeste expose déjà des contributions `layouts`, mais la runtime publique ne formalise pas proprement l’enregistrement et le cycle de vie de ces layouts. L’exemple SDK actuel contourne la surface avec des casts ad hoc.
+
+## Pourquoi c’est global
+Ce n’est pas spécifique à Android: tout plugin de dev peut vouloir afficher un panneau d’état, un tableau, un viewer de logs, une vue de diagnostic, etc.
+
+## Ce que ce ticket doit produire
+Une runtime UI/layout publique stable permettant au minimum :
+- enregistrement typé d’un layout
+- props publiques documentées
+- cycle de vie clair
+- persistance/lecture de state si le host la supporte
+- retrait propre via disposable
+
+## Contraintes d’architecture
+- Pas de dépendance à des détails runtime privés.
+- Contrat explicite sur le rendu et la sérialisation du state plugin.
+
+## Non-objectifs
+- Pas d’imposer un design system plugin complet.
+- Pas d’API spécifique aux vues Android.
+
+## Critères d’acceptation
+- L’exemple SDK n’a plus besoin de cast ad hoc pour enregistrer un layout.
+- La surface publique suffit pour un panneau plugin de dev non trivial.

.ideai/tickets/128/issue.md

@@ -0,0 +1,17 @@
+---
+id: "053f079d-1dfd-48bb-85a2-2dfa8d237999"
+number: 128
+title: "SDK plugins: typer et stabiliser la runtime UI/layout publique"
+status: "closed"
+priority: "medium"
+sprint: null
+links: [{"target":"#123","kind":"blocks"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785662026717
+updatedAt: 1785881187622
+version: 5
+---
+Formaliser la surface runtime publique pour les contributions UI/layout des plugins afin d’éviter les casts ad hoc et de permettre des panneaux/plugins de dev riches sur base stable.

.ideai/tickets/129/carnet.md

@@ -0,0 +1,30 @@
+---
+issueRef: "#129"
+version: 6
+updatedBy: {"kind":"user"}
+updatedAt: 1785881187631
+---
+## Problème
+Chaque plugin de développement devrait aujourd’hui rescanner lui-même le workspace pour reconstruire une vision de la structure projet. Cela duplique les heuristiques et rend l’écosystème fragile.
+
+## Pourquoi c’est global
+Android n’est qu’un cas parmi d’autres. Les plugins pour monorepos JS, workspaces Rust, Python multi-env, etc. ont tous besoin d’une lecture structurée minimale du projet.
+
+## Ce que ce ticket doit produire
+Une API publique d’analyse/requête permettant idéalement :
+- liste de fichiers ou sous-ensembles pertinents
+- conventions détectées
+- modules/units logiques quand connus
+- graphes simples ou métadonnées projet de base
+- résultats structurés et bornés, pas un AST universel magique
+
+## Dépendances
+- Dépend de `#124` car l’analyse repose au minimum sur l’accès contrôlé au workspace.
+
+## Non-objectifs
+- Pas d’indexation sémantique profonde de tous les langages.
+- Pas de modèle Android-only (Gradle modules, variants, etc.) dans l’API publique de base.
+
+## Critères d’acceptation
+- Un plugin peut interroger la structure du projet sans rescanner tout le disque lui-même.
+- Le contrat reste utile à plusieurs stacks et ne fuit pas des abstractions internes.

.ideai/tickets/129/issue.md

@@ -0,0 +1,17 @@
+---
+id: "550fe7ca-8a25-4529-be2e-2fd79c7ddde4"
+number: 129
+title: "SDK plugins: exposer une API publique d’analyse/requête de structure projet"
+status: "closed"
+priority: "medium"
+sprint: null
+links: [{"target":"#123","kind":"blocks"},{"target":"#124","kind":"dependsOn"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785662026738
+updatedAt: 1785881187631
+version: 6
+---
+Ajouter au SDK plugin une API publique pour interroger la structure d’un projet (fichiers, modules, graphes simples, conventions détectées) sans obliger chaque plugin à rescanner le workspace depuis zéro.

.ideai/tickets/13/carnet.md

@@ -1,8 +1,8 @@
 ---
 issueRef: "#13"
-version: 18
+version: 19
 updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
-updatedAt: 1784184002362
+updatedAt: 1784193634690
 ---
 
 # Ticket #13 — Server/client mode (carnet de chantier)

.ideai/tickets/13/issue.md

@@ -2,7 +2,7 @@
 id: "036783fa-9856-4643-8c28-653b93ac36e1"
 number: 13
 title: "Server/client mode"
-status: "inProgress"
+status: "closed"
 priority: "low"
 sprint: "028179b1-eaf4-41e9-9c1f-7c37125117e6"
 links: []
@@ -10,7 +10,7 @@ agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}
 createdBy: {"kind":"user"}
 updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
 createdAt: 1783184188272
-updatedAt: 1784184002362
-version: 18
+updatedAt: 1784193634690
+version: 19
 ---
 J'aimerais pouvoir utiliser IdeA sous forme de client/server. C'est a dire que IdeA aurait son backend sur une machine et son interface qui serait un frontend web. Les agents etc seraient tous côté server. C'est a dire que la cli de Claude serait celle côté serveur, l'interface client ne serait que l'affichage frontend, une UI. Je pense que tout est faisable, il faudrait cependant parler du côté CLI. Est ce qu'il serait possible de garde rle CLI natif comme il est actuellement, de l'afficher côté client tout en gardant l'installation claude code, codex etc côté serveur ? Peut etre qu'en ssh ça passerait ? Ce ticket ne pourra pas être fait en autonomie par un agent sans une review agent-utilisateur avant.

.ideai/tickets/130/carnet.md

@@ -0,0 +1,31 @@
+---
+issueRef: "#130"
+version: 6
+updatedBy: {"kind":"user"}
+updatedAt: 1785881187639
+---
+## Problème
+Un plugin de développement doit souvent lire ou modifier des documents structurés. Sans primitive publique, chaque plugin doit réimplémenter parsing, validation et patching, avec un risque élevé de corruption ou d’incohérence.
+
+## Pourquoi c’est global
+Le besoin concerne JSON, YAML, TOML, XML, propriétés, DSL de config, et potentiellement d’autres formats. Android n’est qu’un consommateur parmi d’autres.
+
+## Ce que ce ticket doit produire
+Une API publique de documents/config structurés permettant idéalement :
+- lecture d’un document typé ou semi-structuré
+- édition contrôlée/patch ciblé
+- sérialisation stable
+- erreurs structurées
+- capacité d’évolution format par format
+
+## Dépendances
+- Dépend de `#124` car il faut d’abord un accès fichier/workspace public.
+
+## Garde-fous
+- Commencer petit si nécessaire; ne pas promettre tous les formats d’un coup.
+- Préférer une abstraction extensible plutôt qu’un parser universel monolithique.
+- Ne pas embarquer des helpers Android-only.
+
+## Critères d’acceptation
+- Le SDK expose une primitive réutilisable pour lire et mettre à jour un document de config sans bricolage spécifique par plugin.
+- Le contrat précise clairement quels formats sont supportés dans le premier lot.

.ideai/tickets/130/issue.md

@@ -0,0 +1,17 @@
+---
+id: "07a76880-f176-4fc8-b1d3-732a88a8c837"
+number: 130
+title: "SDK plugins: exposer une API publique de documents de configuration structurés"
+status: "closed"
+priority: "medium"
+sprint: null
+links: [{"target":"#123","kind":"blocks"},{"target":"#124","kind":"dependsOn"}]
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"user"}
+createdAt: 1785662026750
+updatedAt: 1785881187639
+version: 6
+---
+Ajouter au SDK plugin une API publique pour lire/mettre à jour des documents de configuration structurés via un modèle générique plutôt que forcer chaque plugin à réimplémenter son parsing/patching.

.ideai/tickets/131/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#131"
+version: 2
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1785748044208
+---

.ideai/tickets/131/issue.md

@@ -0,0 +1,39 @@
+---
+id: "4092a7bf-5abb-4056-9e6d-226c392b2279"
+number: 131
+title: "Configurer l'effort par agent avec presets adaptatifs selon le profil AI"
+status: "closed"
+priority: "medium"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1785687359220
+updatedAt: 1785748044208
+version: 2
+---
+Objectif: permettre de choisir l'effort de chaque agent, idéalement via une droplist qui s'adapte au profil AI sélectionné (ex: Codex, Claude Code, OpenCode), tout en conservant un fallback sûr.
+
+Cadrage validé en pré-analyse:
+- Faisabilité: oui.
+- Recommandation produit/contrat: approche hybride contrôlée.
+- UI recommandée: droplist dépendante du profil AI + option "Personnalisé" ouvrant un champ texte/valeur libre si nécessaire.
+
+Attendus de conception:
+- Le profil AI déclare ses options natives d'effort/presets quand elles existent.
+- La UI affiche ces options dans une droplist ordonnée du plus léger au plus profond.
+- Si le provider n'expose pas d'options propres, fallback vers des presets génériques (ex: Rapide / Standard / Approfondi) clairement marqués comme options par défaut.
+- Une option "Personnalisé" reste disponible pour couvrir les providers ou cas non modélisables proprement.
+
+Attendus de contrat:
+- Ajouter sur le profil AI un mécanisme déclaratif d'options d'effort (ex: effort_options avec label + valeur interne + éventuels hints).
+- Le DTO d'agent doit persister soit un preset choisi, soit une valeur brute personnalisée.
+- Prévoir la rétrocompatibilité avec les profils/configs existants, notamment les champs Codex déjà proches de cette notion.
+
+Risques à traiter:
+- Mapping imparfait entre presets UI et paramètres natifs des providers.
+- Cohérence des libellés entre providers.
+- Découverte UX de l'option "Personnalisé".
+- Rétrocompatibilité/persistance sur les profils existants.

.ideai/tickets/132/carnet.md

@@ -0,0 +1,6 @@
+---
+issueRef: "#132"
+version: 2
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1785748044221
+---

.ideai/tickets/132/issue.md

@@ -0,0 +1,41 @@
+---
+id: "37c98a91-ee51-42b3-b804-8c0732784e11"
+number: 132
+title: "Ajouter un outil MCP IdeA pour éditer le contexte projet global"
+status: "closed"
+priority: "medium"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1785687502830
+updatedAt: 1785748044221
+version: 2
+---
+Objectif: permettre à un agent autorisé d'éditer le contexte projet global via un outil MCP IdeA dédié, au lieu de passer uniquement par une proposition enregistrée.
+
+Constat actuel:
+- Le contexte projet global est lisible via `idea_context_read`.
+- Son évolution passe aujourd'hui par `idea_context_propose` sans `target`, ce qui enregistre une proposition pour validation mais n'applique pas directement la modification.
+- Pour certains workflows d'orchestration, il manque une capacité native explicite d'édition contrôlée du contexte projet global.
+
+Attendu produit/technique:
+- Introduire un outil MCP IdeA dédié pour mettre à jour le contexte projet global.
+- Définir clairement qui peut l'utiliser (ex: Main uniquement, ou liste d'agents autorisés).
+- Préserver les garde-fous de concurrence et de traçabilité déjà attendus sur les contextes.
+- Clarifier la relation entre ce nouvel outil et `idea_context_propose` (complément, remplacement partiel, ou voie restreinte selon les droits).
+
+Points à cadrer:
+- Modèle d'autorisation: quels agents peuvent écrire le contexte global.
+- Concurrence/versioning: écrasement simple vs contrôle optimiste.
+- Auditabilité: auteur, date, historique/provenance des changements.
+- UX/runtime: comportement si un agent non autorisé tente l'opération.
+- Compatibilité avec la règle actuelle de single-writer réservée à l'orchestrateur.
+
+Critères de sortie:
+- Contrat MCP défini.
+- Règles d'autorisation explicites.
+- Comportement d'erreur et de concurrence défini.
+- Décision documentée sur la coexistence avec `idea_context_propose`.