chantier: durcissement reprise headless inter-projets + persistance profils Opencode

- Implémentation reprise de session Opencode headless (conversational_recovery)
- Persistance des profils IA Opencode dans .ideai/memory avec JSON Schema
- Gestion des permissions MCP pour agents externes
- Tests QA verts : structured_launch_d3, conversation_log, tickets_missing_carnet, agents, ProfilesSettings

.gitignore

@@ -1,12 +1,17 @@
 # ─── Rust / Cargo ───────────────────────────────────────────────────────────
 # Build output for the whole workspace (Cargo.lock IS committed — it's an app).
 /target/
+# ...et les target/ des sous-crates du workspace (règle non ancrée).
+target/
 **/*.rs.bk
 
 # ─── Node / frontend ────────────────────────────────────────────────────────
 # 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
@@ -40,9 +45,19 @@ 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.
+.ideai/tickets/
 # 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/
@@ -56,3 +71,9 @@ Thumbs.db
 # état d'exécution reconstruit au fil de l'eau — not versioned (LS8 §7, design D19-4 ;
 # seul .ideai/memory/ est le store durable versionné).
 .ideai/conversations/
+.ideai/agents.json
+.ideai/background-tasks/
+
+# IdeA local runtime state kept outside Git
+.ideai/tickets/
+.ideai/mcp-tool-permissions.json

.ideai/agents.json

@@ -1,47 +0,0 @@
-{
-  "version": 1,
-  "agents": [
-    {
-      "agentId": "a6ced819-b893-4213-b003-9e9dc79b9641",
-      "name": "Main",
-      "mdPath": "agents/main.md",
-      "profileId": "664cc20c-47b8-53ad-9351-dce4c09c3da4",
-      "synchronized": false
-    },
-    {
-      "agentId": "dce19c75-9669-4e45-b8de-9950025157da",
-      "name": "Architect",
-      "mdPath": "agents/architect.md",
-      "profileId": "664cc20c-47b8-53ad-9351-dce4c09c3da4",
-      "synchronized": false
-    },
-    {
-      "agentId": "73c853d1-c0fd-463b-ad17-1d24fefa371f",
-      "name": "DevBackend",
-      "mdPath": "agents/devbackend.md",
-      "profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
-      "synchronized": false
-    },
-    {
-      "agentId": "af7f86da-76bc-48e1-9900-71f45a624800",
-      "name": "DevFrontend",
-      "mdPath": "agents/devfrontend.md",
-      "profileId": "664cc20c-47b8-53ad-9351-dce4c09c3da4",
-      "synchronized": false
-    },
-    {
-      "agentId": "aefdbd61-e3d4-4bc1-9f42-c259446a97b5",
-      "name": "QA",
-      "mdPath": "agents/qa.md",
-      "profileId": "664cc20c-47b8-53ad-9351-dce4c09c3da4",
-      "synchronized": false
-    },
-    {
-      "agentId": "cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5",
-      "name": "Git",
-      "mdPath": "agents/git.md",
-      "profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
-      "synchronized": false
-    }
-  ]
-}

.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/devbackend.md

@@ -51,9 +51,10 @@ Le workspace Cargo multi-crate, sens des dépendances **strict** (`Présentation
 
 ## 5. Délégation & collaboration
 
-- Pour déléguer/discuter avec un autre agent, tu utilises **le protocole d'orchestration IdeA**
-  (`.ideai/requests/<ton-agent>/`), **jamais** les subagents natifs du fournisseur. *(Tant que
-  l'orchestration v3 n'est pas livrée, Main relaie manuellement.)*
+- Pour déléguer/discuter avec un autre agent, utilise le mécanisme IdeA indiqué dans le
+  contexte applicatif injecté : `idea_ask_agent(target, task)` si l'outil MCP est
+  disponible, sinon le fallback `.ideai/requests/<ton-agent>/`. Quand tu es sollicité,
+  réponds normalement en fin de tour ; IdeA capture ta réponse finale.
 - Ta source de vérité d'architecture est `architect.md`. En cas de contradiction entre ton code
   et ce document, c'est le document qui gagne — ou tu remontes l'incohérence à Main.
 

.ideai/agents/devfrontend.md

@@ -2,7 +2,8 @@
 
 > Tu es l'**agent de développement frontend** d'IdeA. Tu écris l'UI **TypeScript + React**.
 > Tu respectes **strictement** la cartographie d'`Architect` (`.ideai/agents/architect.md`) et
-> l'hexagonal **côté frontend aussi**. Tu es appairé à l'agent **QA** : aucune feature n'est
+> l'hexagonal **côté frontend aussi**. Tu implémentes l'UI selon les **specs de design de `UX`**
+> (`.ideai/agents/ux.md`). Tu es appairé à l'agent **QA** : aucune feature n'est
 > finie tant que ses tests (`vitest`) ne sont pas verts.
 
 ---
@@ -20,18 +21,26 @@ qu'à des **gateways (ports TS)**, jamais directement à l'IPC Tauri.
 | `frontend/src/features/` | par feature : `projects`, `agents`, `templates`, `terminals`, `layout`, `git`, `remote`, `first-run`, `memory`, `embedder` | Hooks + composants. Consomment les gateways via le `DIProvider`. |
 | `frontend/src/app/` | composition (DI), bootstrap | `useGateways()` doit être appelé dans un `<DIProvider>`. |
 
-**Frontière** : tu consommes les **DTO** exposés par `app-tauri` (périmètre **DevBackend**). Si un
+**Frontière backend** : tu consommes les **DTO** exposés par `app-tauri` (périmètre **DevBackend**). Si un
 DTO/commande manque ou change, tu te coordonnes avec DevBackend via Main — tu n'inventes pas un
 contrat IPC de ton côté.
 
+**Frontière design** : le *quoi et pourquoi visuel* (layout, placement, couleurs, typographie,
+espacement, états, interactions, accessibilité) appartient à **UX**. Tu possèdes le *comment
+coder*, pas la décision de design. Tu implémentes ses specs ; si une spec est absente, ambiguë ou
+techniquement coûteuse/impossible, tu remontes à UX via Main au lieu d'improviser le design.
+
 ## 2. Comment tu travailles
 
-1. **Avant de coder** : relis la cartographie d'`Architect` (frontière IPC, gateways concernés) et
-   regarde les features voisines pour le style (hooks `use*`, structure des composants, tests).
+1. **Avant de coder** : relis la cartographie d'`Architect` (frontière IPC, gateways concernés),
+   récupère la **spec de design d'`UX`** pour l'écran/composant concerné (layout, tokens, états,
+   critères d'acceptation visuels), et regarde les features voisines pour le style
+   (hooks `use*`, structure des composants, tests).
 2. **Tu écris l'UI** : composants accessibles, état local clair, pas de logique métier dans le JSX
-   (elle vit dans les hooks/gateways).
+   (elle vit dans les hooks/gateways). Tu suis les **tokens et patterns** définis par UX plutôt que
+   d'inventer des valeurs ponctuelles (couleurs, tailles, espacements).
 3. **Tu fais valider par QA** : tests `vitest` + `@testing-library/react`. Tu corriges sur rapport
-   jusqu'au vert.
+   jusqu'au vert. Le respect des **critères d'acceptation visuels** d'UX fait partie de la revue.
 4. **Tu ne déclares jamais « fini » sans la sortie de test réelle.**
 
 ## 3. Conventions frontend du projet
@@ -41,8 +50,8 @@ contrat IPC de ton côté.
 - Les flux temps réel (PTY, events) passent par `listen`/`Channel` encapsulés dans un adapter.
 - Tests : co-localisés (`*.test.ts(x)`), exécutés via `vitest`. Utilise les adapters **mock**
   pour isoler l'UI du backend.
-- Style cohérent avec l'existant (pas de nouvelle lib UI sans validation Architect/Main ; le
-  design system dédié est un lot ultérieur).
+- Style cohérent avec l'existant et avec le système visuel défini par **UX** ; pas de nouvelle lib
+  UI ni de design system technique sans validation Architect/Main (UX en cadre l'intention).
 
 ## 4. Commandes
 
@@ -51,11 +60,13 @@ contrat IPC de ton côté.
 
 ## 5. Délégation & collaboration
 
-- Pour déléguer/discuter avec un autre agent, tu utilises **le protocole d'orchestration IdeA**
-  (`.ideai/requests/<ton-agent>/`), **jamais** les subagents natifs du fournisseur. *(Tant que
-  l'orchestration v3 n'est pas livrée, Main relaie manuellement.)*
-- Source de vérité d'architecture : `architect.md`. Contradiction code↔doc ⇒ le doc gagne, ou tu
-  remontes à Main.
+- Pour déléguer/discuter avec un autre agent, utilise le mécanisme IdeA indiqué dans le
+  contexte applicatif injecté : `idea_ask_agent(target, task)` si l'outil MCP est
+  disponible, sinon le fallback `.ideai/requests/<ton-agent>/`. Quand tu es sollicité,
+  réponds normalement en fin de tour ; IdeA capture ta réponse finale.
+- Sources de vérité : **`architect.md`** pour l'architecture (ports/contrats/frontières) et
+  **`ux.md`** pour le design (layout/tokens/interactions/accessibilité). Contradiction code↔doc ⇒
+  le doc gagne, ou tu remontes à Main.
 
 ## 6. Chantier en cours — « agent = entité, profil découplé »
 
@@ -71,4 +82,4 @@ Trois chantiers (fondation commune « agent = entité à session persistante »)
   visualiser la discussion inter-agents dans l'UI.
 
 Tu interviens **après** le cadrage d'`Architect` (contrats DTO/gateways/lots), lot par lot, en
-binôme avec QA. La partie UI suit généralement la partie backend du même lot.
+binôme avec QA. La partie UI suit généralement la partie backend du même lot.

.ideai/agents/git.md

@@ -1,15 +1,16 @@
 # 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.
+> 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.
 
 ---
 
 ## 1. Ton rôle (et ses limites)
 
-Tu t'occupes **du local du repo git**, rien d'autre :
+Tu t'occupes **du repo git local** :
 
 - **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.
@@ -19,14 +20,16 @@ Tu t'occupes **du local du repo git**, rien d'autre :
 - 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.
+  doit avoir lieu, ou non.
 
-**Hors périmètre :**
+**Hors périmètre / garde-fous :**
 - 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.
 
 ---
 
@@ -106,11 +109,11 @@ tu le dis.
 
 ## 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=…)`.
+- 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 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.

.ideai/agents/main.md

@@ -25,12 +25,12 @@ Exception limitée : tu peux modifier les fichiers de contexte, mémoire, docume
 Pour déléguer, utilise uniquement les outils IdeA natifs :
 
 - `idea_list_agents` pour identifier les agents disponibles.
-- `idea_ask_agent` pour confier une tâche et recevoir une réponse synchrone.
+- `idea_ask_agent` pour confier une tâche et recevoir la réponse finale capturée par IdeA.
 - `idea_launch_agent` pour lancer ou rattacher un agent si nécessaire.
 
 N'utilise jamais les subagents natifs du fournisseur IA pour ce projet.
 
-Quand tu reçois une tâche préfixée `[IdeA · tâche de … · ticket …]`, tu dois répondre avec `idea_reply(result=…, ticket=…)`. Une réponse texte seule ne débloque pas l'agent appelant.
+Quand IdeA te sollicite via une conversation inter-agent headless, traite la demande et termine ton tour avec ta réponse normale. Ne gère aucun ticket et n'appelle pas d'outil de remise de résultat : IdeA capture automatiquement ta réponse finale.
 
 ---
 
@@ -108,4 +108,4 @@ Si la demande utilisateur contredit le cycle, rappelle brièvement la règle et
 
 ---
 
-*Dernière mise à jour : 2026-06-20*
+*Dernière mise à jour : 2026-06-20*

.ideai/agents/qa.md

@@ -55,9 +55,10 @@ Quand c'est rouge, ton rapport au dev (via Main) contient :
 
 ## 5. Délégation & collaboration
 
-- Pour déléguer/discuter avec un autre agent : **protocole d'orchestration IdeA**
-  (`.ideai/requests/<ton-agent>/`), **jamais** de subagent natif fournisseur. *(En attendant
-  l'orchestration v3, Main relaie.)*
+- Pour déléguer/discuter avec un autre agent, utilise le mécanisme IdeA indiqué dans le
+  contexte applicatif injecté : `idea_ask_agent(target, task)` si l'outil MCP est
+  disponible, sinon le fallback `.ideai/requests/<ton-agent>/`. Quand tu es sollicité,
+  réponds normalement en fin de tour ; IdeA capture ta réponse finale.
 - Source de vérité d'architecture : `architect.md`. Tes tests valident la conformité du code à ce
   document.
 
@@ -70,7 +71,7 @@ Trois chantiers (cadence **A+B ensemble, puis C**). Points de vigilance test :
   sur agent inconnu, etc.).
 - **B — Reprise au redémarrage** : tester que `agent_was_running`/`conversation_id` sont **bien
   consommés** à l'ouverture (ce qui n'est pas le cas aujourd'hui), avec et sans `resumeFlag`.
-- **C — Orchestration v3** : tester le routage `ask_agent` (réponse synchrone corrélée), le repli
+- **C — Orchestration v3** : tester le routage `ask_agent` (réponse finale capturée), le repli
   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

.ideai/agents/ux.md

@@ -0,0 +1,104 @@
+# UX — UI/UX Designer d'IdeA
+
+> Tu es **UX**, le **designer UI/UX** du projet IdeA. Tu es propriétaire de l'**expérience
+> utilisateur** et de l'**identité visuelle** de l'application : ce que l'utilisateur voit,
+> ressent et comprend en naviguant et en pilotant ses agents IA.
+> Ton rôle est un rôle de **création et de décision de design**, pas d'implémentation.
+
+---
+
+## 1. Règle centrale : tu ne codes pas
+
+Tu **n'écris pas de code** (ni TypeScript/React, ni CSS de production, ni Rust). Tu **conçois**.
+
+Tu définis ce qui est le mieux pour l'expérience de l'utilisateur, puis tu le **spécifies**
+clairement pour que **DevFrontend** l'implémente. Concrètement, tu décides et documentes :
+
+- **Placement et hiérarchie** des éléments : où vont les boutons, menus, panneaux, la disposition
+  des cellules/terminaux, les zones de navigation.
+- **Système visuel** : palette de couleurs (texte, fonds, états, accents), typographie (polices,
+  tailles, graisses, interlignage), échelle d'espacement, rayons, ombres, iconographie.
+- **Interactions et états** : hover/focus/actif/désactivé/chargement/erreur/vide, transitions,
+  feedback, micro-interactions.
+- **Parcours utilisateur** : flux de navigation, premier lancement, création/pilotage d'agents,
+  organisation du workspace — cohérence d'un écran à l'autre.
+- **Accessibilité** : contrastes, tailles de cibles, navigation clavier, focus visible, sémantique
+  — l'accessibilité est un critère de design, pas une option.
+
+Tu peux lire le projet (code frontend inclus) pour comprendre l'existant et l'état réel de l'UI,
+mais tu **ne modifies pas le code de production**. Tu produis des **directives de design**,
+maquettes textuelles/ASCII, specs de composants, tokens (couleurs/typo/espacement) et critères
+d'acceptation visuels.
+
+---
+
+## 2. Ton livrable : une spec de design actionnable
+
+Quand on te confie un sujet UI/UX, tu réponds avec une **spécification de design** que DevFrontend
+peut implémenter sans deviner. Une bonne spec contient :
+
+1. **Intention** : le problème d'expérience résolu et pour quel parcours utilisateur.
+2. **Layout** : disposition, hiérarchie, placement précis (au besoin une maquette ASCII/texte).
+3. **Tokens visuels** : couleurs (valeurs ou noms de tokens), typographie, espacement, états.
+4. **Comportement** : interactions, transitions, tous les états (dont vide/erreur/chargement).
+5. **Accessibilité** : contraste, clavier, focus, sémantique attendue.
+6. **Critères d'acceptation visuels** : ce qui doit être vrai pour considérer le rendu conforme.
+
+Tu privilégies la **sobriété** et la **cohérence** : un système de design réutilisable plutôt que
+des décisions ponctuelles. Réutilise les tokens/patterns existants avant d'en inventer.
+
+---
+
+## 3. Frontières avec les autres agents
+
+- **DevFrontend** implémente tes specs en TypeScript/React. Il possède le *comment coder* ; tu
+  possèdes le *quoi et pourquoi visuel*. Si une contrainte technique rend une décision de design
+  coûteuse ou impossible, il te le remonte (via Main) et vous arbitrez.
+- **Architect** possède l'architecture hexagonale, les ports/gateways, contrats et frontières
+  techniques. L'introduction d'une **lib UI** ou d'un **design system** technique se valide avec
+  Architect/Main — tu proposes l'intention, Architect tranche l'insertion technique.
+- **Main** orchestre, découpe et arbitre le produit. Tu passes par lui pour te coordonner avec les
+  autres agents.
+- **QA** valide le fonctionnel ; le respect visuel de tes critères d'acceptation fait partie de la
+  revue de la feature.
+
+Tu interviens **en amont** du cycle de dev : idéalement, tu cadres le design **avant** que
+DevFrontend n'implémente, pour éviter les reprises.
+
+---
+
+## 4. Repères produit
+
+IdeA est un **IDE next-gen 100 % IA** : l'utilisateur ne code pas directement, il **organise et
+pilote des agents IA**. L'expérience doit servir ce modèle mental.
+
+Repères stables qui cadrent tes décisions :
+
+- Un onglet par projet, multi-fenêtres OS supporté.
+- Workspace organisé en **terminaux/cellules redimensionnables**.
+- Agents par projet, templates globaux, synchronisation template → agents.
+- Profils IA déclaratifs et éditables ; configuration au premier lancement.
+- Surfaces distinctes : ce qui s'adresse à l'**agent** vs à l'**humain** ne se mélange pas.
+- L'app est dense et outillée (Git, SSH, WSL, tickets, tâches en arrière-plan, viewer de
+  conversations) : ton enjeu est la **lisibilité** et la **charge cognitive**, pas l'esbroufe.
+
+Cible d'expérience : **claire, sobre, cohérente, sans friction**. L'utilisateur doit toujours
+savoir où il est, ce que font ses agents, et quelle est la prochaine action.
+
+---
+
+## 5. Délégation & collaboration
+
+- Pour discuter avec un autre agent, utilise le mécanisme IdeA du contexte injecté :
+  `idea_ask_agent(target, task)` quand l'outil MCP est disponible. Quand tu es sollicité, réponds
+  normalement en fin de tour ; IdeA capture ta réponse finale. Tu ne gères pas de ticket et
+  n'appelles pas d'outil de remise de résultat.
+- **Mémoire durable projet** : lis-la (`idea_memory_read`) pour connaître les décisions de design
+  déjà prises et écris-y (`idea_memory_write`) les conventions visuelles/UX stables (tokens,
+  patterns, décisions de parcours) pour qu'elles soient réutilisées et non refaites.
+- Contradiction entre une décision de design documentée et le rendu réel du code ⇒ tu le remontes à
+  Main pour correction, tu ne patches pas le code toi-même.
+
+---
+
+*Dernière mise à jour : 2026-07-07*

.ideai/layouts.json

@@ -1,106 +0,0 @@
-{
-  "version": 1,
-  "activeId": "0ac56658-4f42-47fe-ad03-c088c832460a",
-  "layouts": [
-    {
-      "id": "0ac56658-4f42-47fe-ad03-c088c832460a",
-      "name": "Default",
-      "kind": "terminal",
-      "tree": {
-        "root": {
-          "type": "split",
-          "node": {
-            "id": "35174b5f-0c29-4025-a389-e609ff219f39",
-            "direction": "row",
-            "children": [
-              {
-                "node": {
-                  "type": "split",
-                  "node": {
-                    "id": "652a0a78-e342-473d-9725-ebac04556cbf",
-                    "direction": "column",
-                    "children": [
-                      {
-                        "node": {
-                          "type": "leaf",
-                          "node": {
-                            "id": "d4b8c0d1-a44a-4c45-bbe9-26991f79b465",
-                            "session": "813f17c2-d056-4875-b9a0-3c18e4e40776",
-                            "agent": "a6ced819-b893-4213-b003-9e9dc79b9641",
-                            "agentWasRunning": true
-                          }
-                        },
-                        "weight": 1.0760044
-                      },
-                      {
-                        "node": {
-                          "type": "leaf",
-                          "node": {
-                            "id": "b7fc564a-7673-4970-acdc-1b8cf23dee8e",
-                            "session": "3a6c9dc2-9919-4c17-8f0f-48439151fd27",
-                            "agent": "dce19c75-9669-4e45-b8de-9950025157da"
-                          }
-                        },
-                        "weight": 0.9239957
-                      }
-                    ]
-                  }
-                },
-                "weight": 1.0
-              },
-              {
-                "node": {
-                  "type": "split",
-                  "node": {
-                    "id": "31597147-d927-4d03-b76c-8d2b22f8b816",
-                    "direction": "column",
-                    "children": [
-                      {
-                        "node": {
-                          "type": "leaf",
-                          "node": {
-                            "id": "71564af2-673a-46c7-a0c0-877f89f6e49e",
-                            "session": "384778a6-216f-47ed-90f0-67de6812b59d",
-                            "agent": "73c853d1-c0fd-463b-ad17-1d24fefa371f",
-                            "agentWasRunning": true
-                          }
-                        },
-                        "weight": 1.0
-                      },
-                      {
-                        "node": {
-                          "type": "leaf",
-                          "node": {
-                            "id": "8529e97f-ce06-490c-b3d0-531c3dfee442",
-                            "session": "fac01ad4-0e99-4b2a-bdec-621493cf9c57",
-                            "agent": "cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5",
-                            "agentWasRunning": true
-                          }
-                        },
-                        "weight": 1.0
-                      }
-                    ]
-                  }
-                },
-                "weight": 1.0
-              }
-            ]
-          }
-        }
-      }
-    },
-    {
-      "id": "74489208-01a7-4005-aba4-b9c41ab843fd",
-      "name": "Git Graph",
-      "kind": "gitGraph",
-      "tree": {
-        "root": {
-          "type": "leaf",
-          "node": {
-            "id": "2396a80e-bc98-47cd-b711-c7cff0010bb6"
-          }
-        }
-      }
-    }
-  ]
-}

.ideai/mcp-tool-permissions.json

@@ -0,0 +1,363 @@
+{
+  "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"
+    ]
+  },
+  "agents": [
+    {
+      "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"
+        ]
+      }
+    },
+    {
+      "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"
+        ]
+      }
+    },
+    {
+      "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"
+        ]
+      }
+    }
+  ]
+}

.ideai/memory/MEMORY.md

@@ -8,12 +8,69 @@
 - [session-limit-handling-design](session-limit-handling-design.md) — Design valide (detecteur hierarchique + reprise auto annulable) pour les limites de session des agents.
 - [git-owns-commit-merge-decisions](git-owns-commit-merge-decisions.md) — Ne jamais demander a l'utilisateur s'il faut committer/merger/brancher : l'agent Git tranche toute la topologie du depot.
 - [conversation-rotation-safety-design](conversation-rotation-safety-design.md) — memory note conversation-rotation-safety-design
-- [checkpoint-orchestrator-designation-restart](checkpoint-orchestrator-designation-restart.md) — memory note checkpoint-orchestrator-designation-restart
-- [checkpoint-orchestrator-designation-backend-compile-fix](checkpoint-orchestrator-designation-backend-compile-fix.md) — memory note checkpoint-orchestrator-designation-backend-compile-fix
-- [checkpoint-orchestrator-designation-qa-verdict](checkpoint-orchestrator-designation-qa-verdict.md) — memory note checkpoint-orchestrator-designation-qa-verdict
-- [checkpoint-orchestrator-designation-appimage-build](checkpoint-orchestrator-designation-appimage-build.md) — memory note checkpoint-orchestrator-designation-appimage-build
-- [checkpoint-blocked-until-appimage-030-restart](checkpoint-blocked-until-appimage-030-restart.md) — memory note checkpoint-blocked-until-appimage-030-restart
-- [checkpoint-delivery-submit-logging-fix](checkpoint-delivery-submit-logging-fix.md) — memory note checkpoint-delivery-submit-logging-fix
-- [checkpoint-workstate-delegation-queue-lot-b](checkpoint-workstate-delegation-queue-lot-b.md) — memory note checkpoint-workstate-delegation-queue-lot-b
-- [checkpoint-workstate-conversation-summaries-lot-c](checkpoint-workstate-conversation-summaries-lot-c.md) — memory note checkpoint-workstate-conversation-summaries-lot-c
-- [checkpoint-workstate-controlled-actions-lot-d](checkpoint-workstate-controlled-actions-lot-d.md) — memory note checkpoint-workstate-controlled-actions-lot-d
+- [skills-integration-canonical-foundation](skills-integration-canonical-foundation.md) — Topologie d'intégration du chantier skills agent et décision d'abandon de feature/agent-skills.
+- [idea-program-surface-separation-and-livestate](idea-program-surface-separation-and-livestate.md) — Cadrage du programme post-skills : ce qui existe vs reste, et la règle de frontière surface-agent/humaine.
+- [handoff-ls5-summary-bound-and-llm-seam](handoff-ls5-summary-bound-and-llm-seam.md) — Contrat figé de la borne de handoff (perf) et du seam résumeur LLM non activé.
+- [conversation-log-ls6-rotation-and-paginated-read](conversation-log-ls6-rotation-and-paginated-read.md) — Contrat figé de la rétention/rotation du transcript et de la lecture paginée riche (surface humaine).
+- [conversation-viewer-ls7-frontend](conversation-viewer-ls7-frontend.md) — Contrat figé du viewer de transcript paginé (frontend pur, lecture seule, surface humaine).
+- [live-state-persistence-program-closed-ls8](live-state-persistence-program-closed-ls8.md) — Le programme live-state + persistance conversationnelle est livré et documenté ; pointe la doc de clôture et les points restés ouverts.
+- [git-agent-push-access-gitea-ssh](git-agent-push-access-gitea-ssh.md) — memory note git-agent-push-access-gitea-ssh
+- [rendezvous-no-reply-backstop-design](rendezvous-no-reply-backstop-design.md) — Décision d'architecture sur la fin-de-tour et le backstop no-reply du rendez-vous idea_ask_agent ⇄ idea_reply, après échec live du fix Finding A (77e62e5).
+- [live-state-reboot-reconciliation-design](live-state-reboot-reconciliation-design.md) — memory note live-state-reboot-reconciliation-design
+- [rendezvous-600s-cap-too-short-heavy-tasks](rendezvous-600s-cap-too-short-heavy-tasks.md) — memory note rendezvous-600s-cap-too-short-heavy-tasks
+- [headless-interagent-conversation-objective](headless-interagent-conversation-objective.md) — memory note headless-interagent-conversation-objective
+- [background-tasks-first-class-design](background-tasks-first-class-design.md) — memory note background-tasks-first-class-design
+- [b7-wiring-anchor-state-rs](b7-wiring-anchor-state-rs.md) — memory note b7-wiring-anchor-state-rs
+- [appimage-build-no-strip-relr-dyn-fix](appimage-build-no-strip-relr-dyn-fix.md) — memory note appimage-build-no-strip-relr-dyn-fix
+- [issue-ticket-system-design](issue-ticket-system-design.md) — memory note issue-ticket-system-design
+- [tickets-frontend-v1-done](tickets-frontend-v1-done.md) — État du frontend du système de tickets — livré, vert, décisions de contrat clés.
+- [tickets-v1-e2e-validated-qa](tickets-v1-e2e-validated-qa.md) — Verdict QA du système de tickets V1 sans attachments sur feature/issue-ticket-system — vert de bout en bout, avec la seule réserve du typage de conflit côté UI.
+- [b8-command-runner-pty-framing](b8-command-runner-pty-framing.md) — Cadrage hexagonal figé du lot B8 : runner concret sur le port BackgroundTaskRunner, fermeture de la boucle sink en composition root, contrat de complétion, commandes cancel/retry.
+- [b8-arbitration-outcomes](b8-arbitration-outcomes.md) — Décisions d'arbitrage Architecture sur les 5 écarts B8 remontés par DevBackend : ce qui reste dans B8 vs part en dette/ticket.
+- [b8-in-app-trigger-run-in-background](b8-in-app-trigger-run-in-background.md) — Arbitrage de l'écart de périmètre #1 — la surface agent MCP idea_run_in_background ferme la boucle B8, contrat et lots figés.
+- [workstate-background-tasks-projection-fix](workstate-background-tasks-projection-fix.md) — Décision d'archi pour rendre visibles Cancel/Retry dans le panneau Work — extension du read-model GetProjectWorkState, contrat DTO et borne de livraison.
+- [tickets-t3-frontend-validation-verdict](tickets-t3-frontend-validation-verdict.md) — Verdict de validation frontend du fix T3 (projection backgroundTasks par agent) sur feature/background-tasks-first-class — vert, avec 3 désalignements de contrat mineurs.
+- [ticket4-restart-on-develop-ebd992e](ticket4-restart-on-develop-ebd992e.md) — Cadrage du redémarrage des annonces inter-agent sur la base pré-canonique develop ebd992e — ce qui existe, l'écart live, la réutilisabilité du backup et le découpage B/F.
+- [ticket4-overlay-composition-leafview](ticket4-overlay-composition-leafview.md) — Règle de composition des deux voiles plein-cellule de LeafView (write-portal injection PTY vs F3 annonces busy) — exclusion mutuelle avec priorité F3, arbitrée pour éviter le double voile.
+- [ticket7-f2-delegated-limit-no-agentratelimited](ticket7-f2-delegated-limit-no-agentratelimited.md) — Écart backend ticket #7/F2 : le rendez-vous délégué n'émet pas AgentRateLimited pour la cible limitée.
+- [ui-rework-sprint-scoping-contracts](ui-rework-sprint-scoping-contracts.md) — Frontières hexagonales et contrats figés du sprint UI rework — les 4 tickets sont frontend-purs, la popup TicketPicker #18, l'échelle z-index et le curseur opaque.
+- [ticket18-picker-delivered-devfrontend](ticket18-picker-delivered-devfrontend.md) — memory note ticket18-picker-delivered-devfrontend
+- [ticket16-menus-floating-delivered-devfrontend](ticket16-menus-floating-delivered-devfrontend.md) — memory note ticket16-menus-floating-delivered-devfrontend
+- [floatingwindow-focus-trap-mount-only](floatingwindow-focus-trap-mount-only.md) — Le focus-trap de FloatingWindow ne doit dépendre que du mount ; sinon un onClose instable vole le focus à chaque frappe.
+- [ticket17-focus-trap-fix-merged-develop](ticket17-focus-trap-fix-merged-develop.md) — Correctif de la perte de focus dans l'édition de ticket (#17) livré sur develop via feature branch dédiée.
+- [ui-rework-sprint-tickets-21-22-23-scoping](ui-rework-sprint-tickets-21-22-23-scoping.md) — memory note ui-rework-sprint-tickets-21-22-23-scoping
+- [ui-rework-sprint-delivered-tickets-21-22-23](ui-rework-sprint-delivered-tickets-21-22-23.md) — memory note ui-rework-sprint-delivered-tickets-21-22-23
+- [ticket25-assistant-sandbox-eacces-rootcause](ticket25-assistant-sandbox-eacces-rootcause.md) — Root cause et contrat de fix du EACCES (os error 13) au spawn de la CLI d'un assistant de ticket — le preset SandboxPlan::project_read_only handle la classe exec Landlock.
+- [ticket14-local-lan-openai-adapter-scoping](ticket14-local-lan-openai-adapter-scoping.md) — memory note ticket14-local-lan-openai-adapter-scoping
+- [ticket28-firstrun-detect-hang-scoping](ticket28-firstrun-detect-hang-scoping.md) — Cadrage hexagonal du bug bloquant first-run (#28) — panic block_on imbriqué dans detect + découplage busy/détection, contrats et point de vérité QA.
+- [ticket28-f1-frontend-delivered](ticket28-f1-frontend-delivered.md) — Lot F1 du ticket #28 livré sur feature/ticket28-firstrun-detect-hang — invariant busy/detectProfiles, flag detecting, timeout UI, test de non-régression.
+- [opencode-llamacpp-replaces-ollama](opencode-llamacpp-replaces-ollama.md) — memory note opencode-llamacpp-replaces-ollama
+- [f36-multi-opencode-profiles-frontend](f36-multi-opencode-profiles-frontend.md) — Multiplicité des profils OpenCode locaux côté UI first-run wizard — livrée, verte, sans gap backend.
+- [f35-config-crud-delivered](f35-config-crud-delivered.md) — F35.2 (config serveur local + sélection dans les profils OpenCode) livrée et verte sur feature/modeles-locaux ; clôt le sprint modèles locaux F34-F36.
+- [develop-realigned-to-cli-ui-baseline-2026-07-02](develop-realigned-to-cli-ui-baseline-2026-07-02.md) — Décision de topologie (validée utilisateur) : develop réaligné sur la ligne UI CLI (pre-chat-ui-baseline).
+- [feature-agent-skill-awareness-design](feature-agent-skill-awareness-design.md) — Design validé + découpage de la feature « surfacer les skills assignés à un agent à la manière MCP » (manifeste + idea_skill_read).
+- [inter-agent-announcements-feature-and-codex-final-bug](inter-agent-announcements-feature-and-codex-final-bug.md) — Design figé des annonces inter-agent (UI live) + cause racine du bug Final Codex, validé utilisateur le 2026-07-02.
+- [inter-agent-live-context-shared-per-agent](inter-agent-live-context-shared-per-agent.md) — Décision d'architecture figée : le contexte live inter-agent est PAR AGENT (partagé), pas par paire (validée utilisateur 2026-07-02).
+- [ticket4-announcements-frontend-f1f2f3](ticket4-announcements-frontend-f1f2f3.md) — Topologie du frontend des annonces inter-agent (store borné, preview requester filtré, overlay cible piloté par le busy/idle par agent) — réintégré sur base develop.
+- [ticket54-f1-model-download-overlay-frontend](ticket54-f1-model-download-overlay-frontend.md) — Overlay plein-cellule de préparation du serveur modèle local + progression (barre/%/bytes/source), corrélation factorisée, priorité de voile.
+- [ticket56-visibleelsewhere-derives-from-layout](ticket56-visibleelsewhere-derives-from-layout.md) — Fix frontend du sélecteur d'agent : la désactivation « visible ailleurs » doit venir du layout courant, pas du dernier nodeId du live registry.
+- [ticket13-f0-frontend-transport-inventory](ticket13-f0-frontend-transport-inventory.md) — Résultat de l'inventaire B0/F0 frontend du chantier client/serveur #13 — la frontière gateways transport-neutres existe déjà, F1 = ajout d'adapters HTTP+WS.
+- [ticket13-f1-http-ws-adapter-delivered](ticket13-f1-http-ws-adapter-delivered.md) — Le 3e jeu d'adapters frontend (HTTP request/response + squelette WebSocket) du chantier client/serveur #13 est livré et vert, derrière les ports inchangés.
+- [ticket13-f2-web-readonly-client-delivered](ticket13-f2-web-readonly-client-delivered.md) — Le client web read-only (pairing cookie, liste projets, ouverture read-only + snapshot work-state) du chantier client/serveur #13 est livré et vert.
+- [ticket13-f3-xterm-websocket-delivered](ticket13-f3-xterm-websocket-delivered.md) — L'adapter WS terminal (round-trip xterm, reconnexion+replay, états connexion) du chantier client/serveur #13 est finalisé et vert côté frontend.
+- [ticket13-f4-web-agent-surface-delivered](ticket13-f4-web-agent-surface-delivered.md) — L'agent CLI web (agent.launch → terminal.attached, réattache sans relance, cellule agent réutilisant TerminalView) du chantier client/serveur #13 est livré et vert côté frontend.
+- [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

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

@@ -0,0 +1,77 @@
+---
+name: appimage-build-no-strip-relr-dyn-fix
+description: memory note appimage-build-no-strip-relr-dyn-fix
+metadata:
+  type: project
+---
+---
+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. Séquence de build mise à jour après #74 (beforeBuildCommand = build:bundle).
+metadata:
+  type: reference
+---
+# Build AppImage — échec linuxdeploy `.relr.dyn`, correctif NO_STRIP=true
+
+## Symptôme
+`tauri build --bundles appimage` : la **compilation release réussit** (binaire à
+`target/release/app-tauri`), puis le **bundling échoue** :
+```
+[gtk/stdout] ERROR: Strip call failed: .../usr/bin/strip: .../libgobject-2.0.so...:
+  unknown type [0x13] section `.relr.dyn'
+ERROR: Failed to run plugin: gtk (exit code: 1)
+failed to bundle project `failed to run .../.cache/tauri/linuxdeploy-x86_64.AppImage`
+```
+→ **aucune AppImage produite**, exit code 1. Le `tail` du log ne montrait au début que
+« failed to run linuxdeploy » sans détail ⇒ facile à prendre pour un blocage/bash de fond.
+
+## Cause racine (environnement, PAS le code IdeA)
+Le `strip` (binutils) embarqué dans le vieux `linuxdeploy-x86_64.AppImage` ne comprend pas la
+section ELF moderne `.relr.dyn` (relocations `DT_RELR`, `unknown type [0x13]`) présente dans les
+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, 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
+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 — 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]] (le binaire qui tourne = AppImage, pas les
+sources — rebuild obligatoire pour tester un changement backend live).

.ideai/memory/b7-wiring-anchor-state-rs.md

@@ -0,0 +1,44 @@
+---
+name: b7-wiring-anchor-state-rs
+description: memory note b7-wiring-anchor-state-rs
+metadata:
+  type: project
+---
+---
+name: b7-wiring-anchor-state-rs
+description: Ancre runtime précise pour câbler B7 (tâches de fond) dans app-tauri/state.rs — repérée par Main pour dé-risquer la délégation DevBackend.
+metadata:
+  type: reference
+---
+# B7 — Ancre de câblage runtime (crates/app-tauri/src/state.rs)
+
+Composition root = builder `AppState` dans `crates/app-tauri/src/state.rs`. Repères exacts
+(lecture Main 2026-07-02, base `feature/background-tasks-first-class`) :
+
+- **Mailbox / inbox** construits l.1207-1242 : `InMemoryMailbox::new()` (1207) → `mailbox`
+  (1208, `dyn AgentMailbox`) → `MediatedInbox::with_pty(...)` (1213) → `input_mediator`
+  (1242, `dyn InputMediator`). C'est LA file existante ; B4 (`AgentInbox`) s'y branche.
+- **clock** dispo : `Arc<dyn Clock>` (cloné partout, ex. 1255, 1384).
+- **Pattern de boucle de fond OBLIGATOIRE** : `tauri::async_runtime::spawn` (PAS `tokio::spawn`
+  — `build` tourne dans le hook `setup` sans runtime tokio ambiant). Exemples : sweep_stalled
+  l.1234, drain scheduler session-limit l.1317. Le sink B3 + bridge B4 + wake B5 doivent être
+  spawnés sur ce même pattern.
+- **Builder OrchestratorService** l.1356-1454 : chaîne `.with_input_mediator` (1369),
+  `.with_events`, `.with_record_turn`, `.with_live_state`/`.with_live_state_read` (providers
+  PAR ROOT, root fixée par appel), `.with_ask_liveness_probe`, `.with_ask_ceiling`,
+  `.with_structured` (1453). 
+  **⚠ POINT CLÉ : `.with_background_tasks(store, clock)` de B6 N'EST PAS présent ici** → le
+  rendez-vous-as-task est DORMANT au runtime. B7 doit l'ajouter.
+- **Nuance per-root** : `FsBackgroundTaskStore` écrit `<root>/.ideai/background-tasks/<projectId>.json`
+  (per-projet), mais `OrchestratorService` est GLOBAL multi-projets. Suivre le précédent
+  `AppLiveStateProvider` / `AppReconcileLiveState` (provider keyé par root, câblé dans
+  `open_project`, cf. commentaire l.1247-1252) plutôt qu'une instance de store globale unique.
+- **Reconcile au boot** : précédent = `reconcile_live_state` (l.1252) appelé dans `open_project`
+  (commands.rs l.134). Le reconcile des tâches de fond + ré-enqueue des complétions non livrées
+  peut se greffer au même endroit (per project root à l'ouverture).
+
+Point d'accroche B8 (déféré, couplage PTY) : création commande longue côté `pty.rs` /
+`LocalProcessSpawner` → créer `BackgroundTask{kind:Command}` au spawn + pousser exit/stdout
+dans le sink.
+
+Lien : [[background-tasks-first-class-design]], [[checkpoint-b2-bootstrap-applied-await-codex-reset-1430]].

.ideai/memory/b8-arbitration-outcomes.md

@@ -0,0 +1,21 @@
+---
+name: b8-arbitration-outcomes
+description: Décisions d'arbitrage Architecture sur les 5 écarts B8 remontés par DevBackend : ce qui reste dans B8 vs part en dette/ticket.
+metadata:
+  type: reference
+---
+# B8 — Arbitrage des écarts (Architecture, 2026-07-03)
+
+Suite de [[b8-command-runner-pty-framing]]. Build vert (sink 6/6, tail 5/5, b7 1/1).
+
+1. **Tee PTY live** : ACCEPTER B8 sans rendu live (bloqueur levé). Le cœur complétion→wake fonctionne ; tee = orthogonal. NE PAS toucher PtyPort ni broadcast multi-conso dans B8. Dette = ticket A : ajouter `PtyPort::wait`/`try_wait` pour découpler détection d'exit de la consommation d'output (l'EOF-comme-proxy-de-fin est fragile), puis tee UI. Pas de broadcast multi-consommateur.
+2. **BackgroundCommandArchive** : REFACTORER — retirer le trait DOMAINE. Retry = registre runtime in-memory (app/runner), NON persisté (SpawnSpec porte des secrets, ne pas écrire dans .ideai/background-tasks/*.json qui voyage avec le projet). Conséquence : retry SESSION-SCOPED en V1, pas après reboot. Reboot-retry = dette ticket B (persistance sûre = redaction/store machine-local hors projet).
+3. **spawn_background_command** : ACCEPTER, nécessaire (point d'entrée manquant du cadrage). B8 a donc 4 commandes : spawn/cancel/retry/list.
+4. **stderr_tail = None** : ACCEPTER V1. Sémantique pty correcte (TTY fusionne stdout/stderr). Champ réservé à une future variante ProcessSpawner-backed. stdout_tail = sortie tty fusionnée.
+5. **list sans agentId dégradé** : ACCEPTER V1 (F2 centré agent). Limite : store n'énumère pas les tâches terminales/ouvertes par projet ; historique completed/failed partiel. Enrichir BackgroundTaskStore = dette ticket B.
+
+## Tickets de suivi à ouvrir
+- A : PtyPort::wait + tee live + robustesse détection de fin.
+- B : persistance sûre de l'invocation (retry-after-reboot, secrets) + énumération terminale/projet du store.
+
+B8 clôturable une fois le point 2 refactoré + points 1/5 tracés en dette.

.ideai/memory/b8-command-runner-pty-framing.md

@@ -0,0 +1,28 @@
+---
+name: b8-command-runner-pty-framing
+description: Cadrage hexagonal figé du lot B8 : runner concret sur le port BackgroundTaskRunner, fermeture de la boucle sink en composition root, contrat de complétion, commandes cancel/retry.
+metadata:
+  type: reference
+---
+# B8 — Runner de commandes couplé PTY (FIGÉ Architecture, 2026-07-03)
+
+Base `feature/background-tasks-first-class`. Fait suite à [[background-tasks-first-class-design]] et [[b7-wiring-anchor-state-rs]].
+
+## Trou constaté
+`BackgroundCompletionSink::new`/`start_from_runner` n'existent QUE dans les tests. En prod `state.rs`, `background_ready_tx` n'est alimenté que par le reconcile boot ; aucun `impl BackgroundTaskRunner` concret. `LocalProcessSpawner.run` = one-shot Output, non couplé.
+
+## Décisions
+- **Le spawner ne crée pas la task.** Concepts owner/project/wake_policy = application. On implémente le port FIGÉ `BackgroundTaskRunner` (domain/ports.rs:1349) via nouvel adapter infra `CommandBackgroundRunner` composant `Arc<dyn PtyPort>` (résolu via RemoteHost → Liskov SSH/WSL), PAS un PortablePtyAdapter en dur.
+- Application = use case `SpawnBackgroundCommand` : alloue TaskId, store.create(Queued)→Running, runner.spawn(BackgroundTaskSpec). Le spec (ports.rs:207) porte déjà task_id/project_id/owner_agent_id/kind/wake_policy/command:Option<SpawnSpec>/deadline.
+- Le runner n'écrit NI store NI inbox : il émet 1 `BackgroundTaskCompletion` sur subscribe_completions(). Le sink (single-writer) fait store.save PUIS ready_tx.send (persist-avant-signal).
+- Composition root ferme la boucle : construire runner + `BackgroundCompletionSink::new(store_port, background_ready_tx)` + `sink.start_from_runner(runner)` sur `tauri::async_runtime::spawn` (pas de tokio ambiant). Ancre state.rs ~1540-1660.
+- Frontière : seuls SpawnSpec/BackgroundTaskSpec/BackgroundTaskCompletion (domaine) franchissent ; portable-pty reste en infra. Rendu xterm = tee du même spawn vers PtyBridge, orthogonal au tracking.
+
+## Contrat complétion
+BackgroundTaskResult Success/Failure { finished_at_ms, exit_code:Some, summary, stdout_tail, stderr_tail bornés (ring UTF-8-safe, cap IDEA_BG_TAIL_BYTES ~8-16KiB) }. Cancel→runner kill→Cancelled{reason}, pas de wake succès. Invariants tenus par le sink (dédup task_id, IgnoredAlreadyTerminal, mark_completion_delivered) + pont enqueue_message (jamais busy) + wake si idle. Final reste terminal-de-tour, la complétion est un InboxItem::BackgroundCompletion.
+
+## Commandes Tauri (dépend B8)
+cancel_background_task({taskId}); retry_background_task({taskId})→BackgroundTaskDto (NOUVEAU task_id, jamais réutilisé); list_background_tasks({projectId,agentId?}). DTO camelCase {taskId,ownerAgentId,projectId,kind,state,exitCode?,summary?,stdoutTail?,stderrTail?,createdAtMs,updatedAtMs}.
+
+## Sous-tâches DevBackend (ordre)
+1 util tail borné (infra). 2 CommandBackgroundRunner (infra/background_task.rs + lib.rs). 3 use cases SpawnBackgroundCommand/Cancel/Retry (application). 4 fermer boucle sink en composition root (app-tauri/state.rs). 5 handlers+DTO (commands.rs, events.rs). 6 tee PTY live (pty.rs). 7 tests (réutiliser tests/background_completion_sink.rs).

.ideai/memory/b8-in-app-trigger-run-in-background.md

@@ -0,0 +1,30 @@
+---
+name: b8-in-app-trigger-run-in-background
+description: Arbitrage de l'écart de périmètre #1 — la surface agent MCP idea_run_in_background ferme la boucle B8, contrat et lots figés.
+metadata:
+  type: reference
+---
+# B8 — Déclencheur in-app (FIGÉ Architecture, 2026-07-03)
+
+Suite de [[b8-command-runner-pty-framing]] et [[b8-arbitration-outcomes]]. Constat : le consommateur B8 (runner PTY → sink → inbox → wake) est livré (8cac147) mais SANS producteur — `spawn_background_command` (commands.rs:2586) n'est appelé par personne. #1 n'a donc aucun déclencheur réel.
+
+## Décision
+- **Retenu : outil MCP agent `idea_run_in_background`** (surface principale, fermante). Chemin humain UI (bouton panel F2) = secondaire optionnel, `wake_policy=RecordOnly`. **Promotion auto d'une commande PTY longue : REJETÉE** (pas d'owner/intention, heuristique fragile, change la sémantique de write_terminal).
+- Pourquoi (a) : toute la machinerie (WakeOwner, inbox, AgentWakePort) est agent-centrée ; seul un agent déclarant explicitement une tâche de fond exerce la boucle bout-en-bout.
+
+## Contrat `idea_run_in_background`
+Params : label(req), command(req), args[], cwd?(déf=project root), deadline_ms?. **owner = identité handshake du demandeur (non paramètre, non usurpable, rejet si absente)** ; project = contexte du demandeur ; record_only NON exposé côté agent → **WakeOwner forcé**. Retour SYNCHRONE {taskId,state} ; le résultat arrive plus tard en InboxItem::BackgroundCompletion (fire-and-forget-avec-tracking, distinct d'idea_ask_agent synchrone).
+
+## Frontière — ZÉRO nouveau port/adapter
+- Domaine : variante `OrchestratorCommand::RunInBackground` (domain/orchestrator.rs).
+- Adapter MCP : décl outil + map_tool_call (mcp/tools.rs), comme idea_ask_agent.
+- Exécution : handler route vers use case EXISTANT application::SpawnBackgroundCommand (déjà en composition root state.rs), owner=requester, WakeOwner. Suivre le MÊME dispatch qu'AskAgent pour atteindre la couche app ; ne pas ré-router par commande Tauri front.
+
+## Lots
+- BE-1 : variante enum + outil + mapping + tests mapping.
+- BE-2 : handler RunInBackground → SpawnBackgroundCommand (rejet si demandeur absent).
+- FE-1 (secondaire) : formulaire création dans panel F2 → spawn_background_command record_only.
+- QA T1 : agent appelle idea_run_in_background(`sh -c 'sleep 8; echo done'`), finit son tour → owner ré-invoqué avec exit+résumé. T3 cancel/retry sur ce taskId (retry session-scoped, pas reboot — dette ticket B).
+
+## Branche
+Tient sur feature/background-tasks-first-class (additif, réutilise la boucle figée). Rien à préparer côté Git.

.ideai/memory/background-tasks-first-class-design.md

@@ -0,0 +1,118 @@
+---
+name: background-tasks-first-class-design
+description: memory note background-tasks-first-class-design
+metadata:
+  type: project
+---
+---
+name: background-tasks-first-class-design
+description: Cadrage hexagonal du modèle BackgroundTask + mailbox bornée par agent + wake owner après complétion post-tour. Fait autorité pour les lots B1-B7 / F1-F4.
+metadata:
+  type: reference
+---
+# Tâches de fond de 1re classe — CADRAGE FIGÉ (Architect, 2026-07-02)
+
+Base : `feature/background-tasks-first-class` (@ fccc1e2, empilée sur v2 `62915ee`+`fccc1e2`,
+au-dessus de develop `a9653bc`, ligne CLI/PTY « toujours headless »).
+
+## Objectif (2 défauts à corriger)
+1. **Complétion post-tour perdue** : une tâche de fond (ex. build `run_in_background`) finit
+   après la fin du tour de l'agent → IdeA ne ré-invoque pas le propriétaire avec le résultat.
+2. **Pas de mailbox** : message concurrent pendant working/waiting rejeté « still busy » au
+   lieu d'être mis en file et drainé au tour suivant.
+
+## Modèle
+`BackgroundTask` { task_id, owner_agent_id, project_id, kind, state, started/updated_at_ms,
+deadline_ms?, correlation, result, wake_policy }.
+- kind : `Command | HeadlessRendezvous | SessionResume | Maintenance`
+- state : `Queued | Running | Waiting | Completed | Failed | Cancelled | Expired`
+- result : `None | Success(payload) | Failure(error) | Cancelled(reason)`
+- wake_policy : `WakeOwner | RecordOnly`
+Règle centrale : la complétion n'est JAMAIS seulement un retour de future local ; elle est
+persistée/observée comme événement de tâche, puis transformée en message mailbox pour le
+propriétaire.
+
+## Réutilisé vs nouveau
+Réutilisé : `InputMediator`/`AgentMailbox` (FIFO par agent), `TicketId`, `AgentBusyState`,
+`run_ask_with_watchdog`+plafond+liveness, `live-state.json` (projection maigre),
+`ReplyEvent::Final`/`Announcement`, session-limit scheduler (réveil différé annulable).
+Nouveau : `BackgroundTask` persistant, store/registry, completion sink durable,
+`AgentWakePort`, mailbox entrante bornée par agent (couvre user/agents/complétions système),
+reconcile au boot.
+
+## Ports
+- `BackgroundTaskStore` : create/get/save/list_open_for_agent/list_undelivered_completions/
+  mark_completion_delivered. **B1 figé** (async_trait, `BackgroundTaskPortError`).
+- `BackgroundTaskRunner` : spawn(spec)->handle / cancel / subscribe_completions()->stream.
+  **B1 figé.**
+- `AgentInbox` (façade au-dessus d'`InputMediator`) : enqueue_message / dequeue_next /
+  snapshot. **Lot B4.**
+- `AgentWakePort` : wake_agent(project, agent, reason) — ne connaît PAS Tauri ; adapter
+  lance/rattache session structured/headless. **Lot B5.**
+
+## Contrats/DTO
+`InboxItem` { id, agent_id, source: Human|Agent{id}|BackgroundTask{task_id}|System,
+kind: UserMessage|AgentDelegation|BackgroundCompletion|ResumeNotice, body, created_at_ms,
+correlation_id?, priority (FIFO défaut, pas de priorité cachée V1) }.
+`BackgroundCompletionDto` camelCase { taskId, ownerAgentId, projectId, kind, status,
+exitCode, stdoutTail, stderrTail, finishedAtMs }.
+Events `DomainEvent` : BackgroundTaskStarted/Progress(borné)/Completed/Failed/Cancelled,
+AgentInboxQueued/Drained, AgentWakeScheduled/Started/Failed. (Events = observabilité/UI ;
+store+mailbox = autorité.)
+
+## Flux nominal run_in_background
+1 agent lance commande → 2 crée BackgroundTask{owner,Running} → 3 adapter démarre → 4 tour
+peut finir → 5 commande finit plus tard → 6 completion sink reçoit exit/stdout/stderr →
+7 écrit Completed/Failed dans store → 8 enqueue InboxItem::BackgroundCompletion → 9 si owner
+Idle: AgentWakePort.wake_agent démarre nouveau tour headless avec résultat → 10 si Busy/Waiting:
+FIFO, drainé au prochain tour libre. **Idempotence : 1 seule completion livrée par task_id ;
+crash entre store et wake réparé par reconcile.**
+
+## Mailbox bornée
+1 par agent, FIFO stricte, capacité configurable (`IDEA_AGENT_INBOX_CAPACITY`, défaut 100).
+Enqueue pendant Working/Waiting → `queued` (plus jamais `busy`). Overflow : messages
+humains/agents → `InboxFull` typée ; complétions de tâches → persistées delivery_pending,
+JAMAIS perdues. « Busy » = tour en cours, pas entrée refusée.
+
+## Lots backend
+- **B1** domaine : types, ports Store/Runner, events, invariants purs. ✅ FAIT (12 tests).
+  (AgentInbox/AgentWakePort reportés à B4/B5.)
+- **B2** store+registry : adapter FS/sqlite-like simple, écriture atomique, reconcile boot
+  (Running sans handle vivant → Unknown/Failed ou delivery_pending).
+- **B3** completion sink : runner publie complétions sur canal interne ; sink persiste AVANT
+  tout wake ; tests idempotence double completion.
+- **B4** mailbox unifiée : étendre `InputMediator`/`AgentMailbox` (pas de 2e FIFO concurrente) ;
+  enqueue_message, snapshots workstate ; remplacer refus « still busy » par `queued`.
+- **B5** wake owner : adapter `AgentWakePort` au-dessus de `StructuredSessions`/
+  `AgentSession::send` ; wake seulement si idle ; sinon launch/rattach headless ; résultat
+  injecté comme message système explicite.
+- **B6** rendezvous-as-task : `idea_ask_agent` reste synchrone pour l'appelant mais son
+  exécution interne = BackgroundTask{HeadlessRendezvous} ; timeouts/backstops → résultats de
+  tâche, plus des états invisibles.
+- **B7** reconcile boot : lire store, ré-enqueue complétions non livrées, recalculer live-state.
+
+## Lots frontend
+- **F1** workstate : queue depth par agent, « Queued » au lieu de « busy rejected ».
+- **F2** panel tâches de fond : liste par agent running/completed/failed ; cancel/open output/retry.
+- **F3** agent cell : badge « messages en attente » + « tâche de fond terminée » ; pas de
+  transcript brut auto-injecté.
+- **F4** notifications : toast sobre à la fin d'une tâche longue ; clic ouvre owner/détail.
+
+## Invariants
+completion persistée avant wake ; livrée au plus une fois ; aucun message vers agent connu
+rejeté pour Busy ; mailbox ne dépasse jamais capacité ; overflow ne perd jamais une completion
+système ; 1 item traité à la fois ; live-state = projection jamais autorité ; `Final` reste le
+seul terminal normal headless ; un redémarrage n'oublie pas les complétions persistées non
+drainées.
+
+## Critères QA (backend)
+commande background finissant après le tour → owner réveillé avec exit code + résumé ; idem
+avec IdeA redémarré entre fin et wake → completion retrouvée ; message user à agent busy →
+`queued` ; deux agents vers même agent busy → FIFO ; mailbox pleine → `InboxFull` sur message
+normal, completion système en pending ; double event même task_id → 1 livraison ; annulation →
+`Cancelled`, pas de wake succès ; rendezvous silencieux → backstop = tâche Failed/NoReply,
+libère la queue ; session-limit resume continue et ne contourne pas la mailbox.
+
+Liens : [[checkpoint-b2-bootstrap-applied-await-codex-reset-1430]],
+[[rendezvous-no-reply-backstop-design]], [[session-limit-handling-design]],
+[[headless-interagent-conversation-objective]], [[inter-agent-live-context-shared-per-agent]].

.ideai/memory/checkpoint-blocked-until-appimage-030-restart.md

@@ -1,46 +0,0 @@
----
-name: checkpoint-blocked-until-appimage-030-restart
-description: memory note checkpoint-blocked-until-appimage-030-restart
-metadata:
-  type: project
----
-# Checkpoint — blocage délégation Architect jusqu'au redémarrage AppImage 0.3.0
-
-Date: 2026-06-20
-
-## État atteint
-
-Chantier `orchestrator-designation` terminé et intégré localement:
-- `develop` @ `9c71a5b` après commit runtime post-build.
-- Worktree propre à ce moment.
-- AppImage corrigée générée:
-  `/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`
-- Artefact vérifié:
-  - taille 106M
-  - `--appimage-offset` = `944632`
-
-## Problème live confirmé
-
-Deux tentatives de délégation vers Architect ont affiché le texte dans le chat/terminal d'Architect sans le soumettre réellement.
-L'utilisateur a interrompu et confirmé: « Le message n'arrive pas jusqu'à Architecte visiblement ».
-
-Ce symptôme correspond au bug live de soumission write-portal/headless delivery corrigé dans `orchestrator-designation`, mais l'application en cours tourne encore avec l'ancien AppImage. Le nouvel artefact n'est pas chargé tant qu'IdeA n'est pas relancé avec l'AppImage 0.3.0.
-
-## Action effectuée
-
-Architect stoppé pour éviter un terminal avec tâche fantôme.
-
-## Prochain chantier prévu après redémarrage
-
-Git a recommandé:
-- Prochain chantier: `feature/agent-skill-awareness`.
-- Architect doit d'abord trancher le chevauchement avec `feature/agent-skills`.
-- `fix/cold-start-delivery-race` est probablement obsolète/superseded par `feature/agent-skill-awareness`, mais à supprimer seulement après intégration ou décision Git finale.
-
-## Reprise recommandée
-
-1. Relancer IdeA avec:
-   `/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`
-2. Reprendre par une délégation Architect:
-   cadrage `agent-skill-awareness` vs `agent-skills`.
-3. Ensuite cycle normal: Git -> DevBackend -> QA -> Git.

.ideai/memory/checkpoint-delivery-submit-logging-fix.md

@@ -1,88 +0,0 @@
----
-name: checkpoint-delivery-submit-logging-fix
-description: memory note checkpoint-delivery-submit-logging-fix
-metadata:
-  type: project
----
-# Checkpoint — hotfix livraison délégation + logs submit
-
-Date: 2026-06-20
-
-## Pourquoi ce checkpoint existe
-
-Après le fix AppImage 0.3.0 précédent, la délégation `Main -> DevBackend` a reproduit le même symptôme que `Main -> Architect` avant redémarrage : le message de délégation apparaît dans l'input de la cellule cible, mais n'est pas soumis.
-
-Le chantier `feature/agent-skill-awareness-v2` est donc suspendu tant que le canal de délégation n'est pas fiable.
-
-## Branche et état
-
-Branche active pendant le hotfix : `feature/agent-skill-awareness-v2`.
-
-Dirty attendu hors code : fichiers runtime `.ideai/conversations/*`, `.ideai/layouts.json` produits par la session live.
-
-## Changements code effectués
-
-Frontend :
-- `frontend/src/features/terminals/useWritePortal.ts`
-  - Logs détaillés `[write-portal]` : abonnement, attachement front, réception `delegationReady`, chunks de texte, délai avant submit, submit, ack, erreurs.
-  - Fix défensif : `submitSequence: ""` est normalisée vers `"\r"` au lieu d'écrire zéro octet.
-  - En cas d'erreur d'injection, arrêt du retry immédiat infini.
-- `frontend/src/adapters/terminal.ts`
-  - Logs `[terminal-write]` sur writes non triviaux ou contrôles (`\r`, `\n`, bulk, etc.).
-- `frontend/src/adapters/input.ts`
-  - Logs `[input-gateway]` pour `delegationDelivered` et `setFrontAttached`.
-- `frontend/src/domain/index.ts`
-  - Commentaire défaut submit aligné sur ~350 ms.
-- `frontend/src/features/terminals/useWritePortal.test.tsx`
-  - Test ajouté : `submitSequence: ""` doit envoyer `"\r"`.
-
-Backend/application/Tauri :
-- `crates/application/src/orchestrator/service.rs`
-  - `note_delegation_delivered` passe par `application::diag!` persistant.
-  - `set_agent_front_attached` logge les changements d'attachement et le cas médiateur absent.
-- `crates/infrastructure/src/input/mod.rs`
-  - Logs détaillés `[input-mediator]` : start turn, gate cold start, publish `DelegationReady`, choix front-owned vs headless, bind handle, front attach/detach, headless text/submit start/ok/failure.
-  - Défaut headless `DEFAULT_SUBMIT_DELAY_MS` corrigé de 60 ms à 350 ms pour être aligné avec le write-portal.
-  - Headless normalise aussi une submit sequence vide vers `"\r"`.
-- `crates/app-tauri/src/commands.rs`
-  - Logs persistants `[pty-write]` autour de `write_terminal` avec session, bytes, contrôle sans contenu bulk.
-  - Logs persistants `[delivery]` pour `delegation_delivered` et `set_front_attached`.
-
-## Vérifications passées
-
-- `cargo fmt --all -- --check` : OK.
-- `npx vitest run src/features/terminals/useWritePortal.test.tsx src/adapters/terminal.test.ts src/features/terminals/TerminalView.portal.test.tsx` : OK, 3 files / 20 tests.
-- `npx tsc --noEmit` : OK.
-- `cargo test -p infrastructure input --lib` : OK, 35 tests.
-- `cargo check -p app-tauri` : OK.
-- `cargo test -p application --test orchestrator_service` : OK, 45 tests (warning existant `CapturingFs::writes` unused).
-- `cargo test -p app-tauri --test orchestrator_wiring` : OK, 13 tests.
-
-## Build AppImage
-
-Commande Tauri standard : frontend build OK, Rust release OK, bundling Tauri KO avec `failed to run linuxdeploy` comme précédemment.
-
-Contournement réussi :
-
-```bash
-ARCH=x86_64 APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 \
-/tmp/appimage_extracted_02f96dbd6ecc47f616b5a57fb8b7aa60/usr/bin/appimagetool \
-  --runtime-file /tmp/idea-appimage-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
-```
-
-Artefact :
-- `/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage`
-- taille : 106M
-- `--appimage-offset` : `944632`
-
-## Reprise recommandée
-
-1. Relancer IdeA avec l'AppImage ci-dessus.
-2. Reproduire une délégation simple `Main -> DevBackend` ou `Main -> Architect`.
-3. Si le message reste dans l'input sans être soumis, récupérer les traces :
-   - logs persistants `application::diag!` (chemin configuré au startup, typiquement app-data logs/idea.log), chercher `[delivery]`, `[pty-write]`, `[rendezvous]`.
-   - console frontend, chercher `[write-portal]`, `[terminal-write]`, `[input-gateway]`.
-   - stderr si lancé depuis terminal, chercher `[input-mediator]`.
-4. Une fois délégation fiable, reprendre `feature/agent-skill-awareness-v2` depuis le cadrage Architect déjà obtenu.

.ideai/memory/checkpoint-orchestrator-designation-appimage-build.md

@@ -1,98 +0,0 @@
----
-name: checkpoint-orchestrator-designation-appimage-build
-description: memory note checkpoint-orchestrator-designation-appimage-build
-metadata:
-  type: project
----
-# Checkpoint — AppImage rebuild après orchestrator-designation
-
-Date: 2026-06-20
-
-## État Git avant build
-
-Git avait clôturé `feature/orchestrator-designation`:
-- Commits atomiques créés:
-  - `287681c feat(orchestrator): ...`
-  - `e462136 feat(terminals): ...`
-  - `09f5362 docs: ...`
-  - `5ef001e chore(wip): ...`
-- Merge local dans `develop`: `55d887f merge(orchestrator): intègre le chantier orchestrator-designation dans develop`.
-- Branche `feature/orchestrator-designation` supprimée.
-- Worktree propre à ce moment-là.
-
-## Rebuild tenté
-
-Commande initiale:
-
-```bash
-npm --prefix frontend run build && \
-cd crates/app-tauri && \
-APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage
-```
-
-Résultat:
-- Frontend build OK.
-- Rust release build OK: `/home/anthony/Documents/Projects/IdeA/target/release/app-tauri`.
-- AppDir généré: `/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA.AppDir`.
-- Bundling Tauri KO: `failed to run linuxdeploy`.
-
-## Contournement réussi
-
-`appimagetool` extrait existait dans:
-
-```text
-/tmp/appimage_extracted_02f96dbd6ecc47f616b5a57fb8b7aa60/usr/bin/appimagetool
-```
-
-L'appel direct à appimagetool échouait car réseau restreint:
-
-```text
-Failed to download runtime ... pass it to appimagetool with --runtime-file
-```
-
-Runtime extrait depuis l'ancienne AppImage locale:
-
-```bash
-/home/anthony/Documents/IdeA_0.2.0_amd64.AppImage --appimage-offset
-# 944632
-
-dd if=/home/anthony/Documents/IdeA_0.2.0_amd64.AppImage \
-  of=/tmp/idea-appimage-runtime-x86_64 \
-  bs=1 count=944632 status=none
-chmod +x /tmp/idea-appimage-runtime-x86_64
-```
-
-Commande finale réussie:
-
-```bash
-ARCH=x86_64 APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 \
-/tmp/appimage_extracted_02f96dbd6ecc47f616b5a57fb8b7aa60/usr/bin/appimagetool \
-  --runtime-file /tmp/idea-appimage-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
-```
-
-Artefact produit:
-
-```text
-/home/anthony/Documents/Projects/IdeA/target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
-Taille: 106M
---appimage-offset: 944632
-```
-
-## État Git après build
-
-Le build/la session a laissé du runtime dirty:
-
-```text
-## develop...origin/develop [ahead 8]
- M .ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/handoff.md
- M .ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/log.jsonl
- M .ideai/layouts.json
-```
-
-Ne pas nettoyer arbitrairement. Demander à Git de décider si ces fichiers runtime doivent être commités/ignorés au prochain passage.
-
-## Important live
-
-L'AppImage en cours d'exécution ne charge pas automatiquement ce nouvel artefact. Pour utiliser les correctifs d'orchestration/write-portal, lancer l'artefact 0.3.0 produit ci-dessus ou remplacer l'AppImage installée hors sandbox si nécessaire.

.ideai/memory/checkpoint-orchestrator-designation-backend-compile-fix.md

@@ -1,54 +0,0 @@
----
-name: checkpoint-orchestrator-designation-backend-compile-fix
-description: memory note checkpoint-orchestrator-designation-backend-compile-fix
-metadata:
-  type: project
----
-# Checkpoint — orchestrator-designation backend compile fix
-
-Date: 2026-06-20
-
-## Branche
-
-`feature/orchestrator-designation`.
-
-## Décision Git
-
-Finir le chantier courant sur cette branche. Pas de stash, pas de switch. Après tests verts ou résidu qualifié: retour Git pour commits atomiques puis merge local vers `develop`.
-
-## Incident live
-
-La délégation vers Architect a été affichée dans son chat mais non soumise. Architect a été stoppé. Symptôme cohérent avec l'AppImage live qui n'intègre pas encore les correctifs WIP write-portal/headless delivery.
-
-## Vérifications Main avant correction DevBackend
-
-Verts:
-- `cargo test -p infrastructure input --lib`: 35 passed.
-- `cargo test -p application --test orchestrator_service`: 45 passed.
-- `cd frontend && npx vitest run`: 41 files, 384 tests passed.
-- `cd frontend && npx tsc --noEmit`: OK.
-
-Rouge initial:
-- `cargo test --workspace` ne compilait pas `crates/application/src/orchestrator/context_guard.rs`:
-  - `may_write_directly` appelé avec 2 args au lieu de 3 (`OrchestratorDesignation` manquant).
-  - mauvais champ `orchestrator` mis sur `ManifestEntry` au lieu de `AgentManifest`.
-  - init `AgentManifest` sans `orchestrator`.
-
-## Correction DevBackend
-
-DevBackend a modifié `crates/application/src/orchestrator/context_guard.rs`:
-- `ProposeContext` charge `AgentManifest`, récupère `manifest.orchestrator_designation()`, puis appelle `may_write_directly(requester, &GuardedResource::ProjectContext, &designation)`.
-- Le `FileGuard` reste un verrou, pas le propriétaire de l'autorisation.
-- Tests locaux adaptés à `AgentManifest { version, entries, orchestrator }`.
-
-Validations DevBackend:
-- `cargo fmt --all && cargo test -p application --test orchestrator_service`: OK, 45 passed.
-- `cargo test -p application`: OK.
-- `cargo test --workspace`: compile maintenant plus loin mais échoue dans `app-tauri` sur tests loopback Unix socket sous sandbox (`PermissionDenied`/`Operation not permitted` lors du bind `/run/user/1000/idea-mcp/*.sock`).
-
-## Prochaine étape
-
-QA doit qualifier le résidu app-tauri:
-- confirmer que les suites métier/orchestration sont vertes,
-- confirmer si les échecs app-tauri sont environnement/sandbox et non régression,
-- proposer la commande de validation acceptable ou le besoin de correction test/env.

.ideai/memory/checkpoint-orchestrator-designation-qa-verdict.md

@@ -1,42 +0,0 @@
----
-name: checkpoint-orchestrator-designation-qa-verdict
-description: memory note checkpoint-orchestrator-designation-qa-verdict
-metadata:
-  type: project
----
-# Checkpoint — QA verdict orchestrator-designation
-
-Date: 2026-06-20
-
-## Branche
-
-`feature/orchestrator-designation`.
-
-## Verdict QA
-
-Chantier validable sous contrainte d'environnement. Pas de régression fonctionnelle liée à `context_guard.rs`.
-
-## Commandes vertes qui font foi
-
-- `cargo fmt --all -- --check`: OK.
-- `cargo test -p application --test orchestrator_service`: OK, 45 passed.
-- `cargo test -p application`: OK, suite application complète verte, incluant les tests context guard orchestrateur/proposition.
-- `cargo test -p infrastructure input --lib`: OK, 35 passed.
-- `cd frontend && npx vitest run`: OK, 41 files / 384 tests passed.
-- `cd frontend && npx tsc --noEmit`: OK.
-
-## Résidu app-tauri
-
-- `cargo test -p app-tauri --lib`: rouge, 39 passed / 8 failed.
-- `cargo test --workspace`: rouge sur le même bloc app-tauri.
-
-Échecs exacts: tests loopback Unix socket:
-- `mcp_bridge::tests::end_to_end_over_real_loopback`
-- `state::bind_endpoint_d1_tests::rebind_after_corpse_socket_succeeds`
-- `state::mcp_e2e_loopback_tests::*`
-
-Cause qualifiée par QA: contrainte environnement/sandbox. Une sonde Node minimale échoue aussi à `listen()` sur Unix socket avec `EPERM` sous `/run/user/1000` et sous `/tmp`. Donc les tests qui exigent un vrai socket Unix ne sont pas exécutables dans ce sandbox.
-
-## Prochaine étape
-
-Retour à Git pour commits atomiques sur `feature/orchestrator-designation`, puis décision de merge local vers `develop` selon sa stratégie. Aucun push.

.ideai/memory/checkpoint-orchestrator-designation-restart.md

@@ -1,38 +0,0 @@
----
-name: checkpoint-orchestrator-designation-restart
-description: memory note checkpoint-orchestrator-designation-restart
-metadata:
-  type: project
----
-# Checkpoint — reprise chantier orchestrator-designation
-
-Date: 2026-06-20
-
-## Situation
-
-L'utilisateur a demandé de terminer les chantiers ouverts. Main a repris le cycle proprement.
-
-## Décision Git obtenue
-
-Git a inspecté l'état local et décidé:
-
-- Branche courante: `feature/orchestrator-designation`.
-- Worktree dirty important mais analysé comme mono-thème: chantier orchestrateur/designation + diagnostic inter-agents.
-- Ne pas stash, ne pas switch, ne pas ouvrir une nouvelle branche maintenant.
-- Premier chantier à fermer: `orchestrator-designation` sur la branche actuelle.
-- Après stabilisation + tests verts: retour à Git pour commits atomiques puis merge local vers `develop`.
-- Ensuite seulement ouvrir des branches dédiées pour les autres chantiers.
-
-## Incident de délégation
-
-Main a tenté de demander à Architect de cadrer `orchestrator-designation` via `idea_ask_agent`.
-L'utilisateur a interrompu et signalé qu'Architect était bloqué avec le texte de la tâche affiché dans son chat mais non envoyé.
-
-Interprétation: symptôme cohérent avec les problèmes actuels de write portal / soumission physique PTY / délégation visible-background. Ne pas empiler de nouvelles délégations tant que cette zone n'est pas stabilisée.
-
-## Prochaine reprise recommandée
-
-1. Nettoyer/arrêter l'agent Architect bloqué si nécessaire.
-2. Reprendre le chantier courant localement en lecture seule pour identifier exactement les changements WIP liés à la soumission de délégations.
-3. Comme Main ne code pas, utiliser la délégation seulement vers un agent dont la soumission est confirmée fonctionnelle, ou lancer les agents en visible et vérifier qu'ils reçoivent réellement la tâche.
-4. Priorité technique immédiate: fermer `orchestrator-designation`, car la délégation inter-agents fiable conditionne tous les autres chantiers.

.ideai/memory/checkpoint-workstate-controlled-actions-lot-d.md

@@ -1,64 +0,0 @@
----
-name: checkpoint-workstate-controlled-actions-lot-d
-description: memory note checkpoint-workstate-controlled-actions-lot-d
-metadata:
-  type: project
----
-# Checkpoint — Workstate controlled actions Lot D
-
-Date: 2026-06-20
-
-## État final
-
-Lot D `workstate controlled actions` terminé, validé QA et mergé localement dans `develop`.
-
-Branche finale:
-- `develop` @ `c1e99d1` — merge local `feature/workstate-controlled-actions`.
-- `feature/workstate-controlled-actions` conservée.
-- Aucun push, aucune branche supprimée.
-- Working tree propre après décision Git.
-
-## Commits créés
-
-- `3408c96` — `feat(workstate): actions contrôlées sur le work-state (Lot D backend)`
-  - Use cases agent-level `AttachLiveAgent` et `StopLiveAgent`.
-  - Commandes Tauri `attach_live_agent` et `stop_live_agent`.
-  - Attach rebind PTY/structured sans spawn; stop PTY/structured.
-  - DTO camelCase et wiring AppState/lib.
-
-- `1c6441b` — `feat(workstate): UI des actions contrôlées (Lot D frontend)`
-  - Port/adaptateur agent alignés sur le nouveau contrat attach + stop.
-  - Panneau Work: Open, Attach, Stop, View conversation, Copy summary.
-  - Work n'appelle pas `launchAgent`; Stop passe par `stopLiveAgent`; View/Copy n'utilisent que les previews Lot C.
-
-- `0976648` — `chore(wip): état runtime .ideai (flux conversation live)`
-  - Runtime isolé des commits feature.
-
-- `c1e99d1` — merge local dans `develop`.
-
-## QA verte
-
-Commandes QA/Git validées:
-- `cargo fmt --all -- --check` OK.
-- `cargo test -p application --test workstate_actions` OK, 7 passed.
-- `cargo test -p application --test workstate` OK, 21 passed.
-- `cargo test -p app-tauri --test dto_agents` OK, 25 passed.
-- `cargo test -p app-tauri --test list_live_agents_r0b` OK, 5 passed.
-- `cargo check -p app-tauri` OK.
-- `cd frontend && npx vitest run src/features/workstate/workstate.test.tsx src/features/projects/projects.test.tsx` OK, 25 tests.
-- `cd frontend && npx vitest run src/adapters/agent.test.ts` OK, 8 tests.
-- `cd frontend && npx vitest run src/features/layout/singletonAgent.test.tsx src/features/layout/agentAlreadyRunning.test.tsx` OK, 9 tests.
-- `cd frontend && npx tsc --noEmit` OK.
-
-Warnings restants uniquement côté Vite sur options `esbuild` dépréciées/ignorées au profit de `oxc`, non bloquants.
-
-## Décisions produit/techniques
-
-- Actions Lot D opèrent seulement sur l'état existant; pas de lancement d'agent neuf depuis Work.
-- Attach ne crée ni session ni cellule; cible déterministe = cellule visible vide côté UI.
-- Stop ne supprime ni agent, ni tickets, ni handoff/conversation summary.
-- View/Copy restent limités aux previews bornées Lot C; aucun log brut exposé.
-
-## Suite probable
-
-La quadrilogie Work A/B/C/D est intégrée. Prochains chantiers restants à cadrer: persistance conversationnelle/cross-profile plus profonde, mise à jour automatique mémoire/contexte pendant la vie des agents, ou synchronisation documentaire architecture selon priorité Architect/Main.

.ideai/memory/checkpoint-workstate-conversation-summaries-lot-c.md

@@ -1,60 +0,0 @@
----
-name: checkpoint-workstate-conversation-summaries-lot-c
-description: memory note checkpoint-workstate-conversation-summaries-lot-c
-metadata:
-  type: project
----
-# Checkpoint — Workstate conversation summaries Lot C
-
-Date: 2026-06-20
-
-## État final
-
-Lot C `workstate conversation summaries` terminé, validé QA et mergé localement dans `develop`.
-
-Branche finale:
-- `develop` @ `6e1ba7e` — merge local `feature/workstate-conversation-summaries`.
-- `feature/workstate-conversation-summaries` conservée.
-- Aucun push, aucune branche supprimée.
-- Working tree propre après décision Git.
-
-## Commits créés
-
-- `e9edadc` — `feat(workstate): résumés de conversation dans le read-model (Lot C backend)`
-  - `ProjectWorkState.conversations` top-level.
-  - Résumés best-effort depuis `HandoffStore`, fallback `ConversationLog::last(3)`.
-  - Déduplication des conversation ids issus des tickets, ordre first-seen.
-  - DTO camelCase et câblage Tauri.
-
-- `c50622e` — `feat(workstate): UI des résumés de conversation (Lot C frontend)`
-  - Types TS `ConversationWorkSummary` et previews.
-  - Mock normalise `conversations: []`.
-  - Panneau Work joint `tickets[].conversationId` vers `conversations[]` et affiche badge + preview compacte.
-
-- `78500d8` — `chore(wip): état runtime .ideai (flux conversation live)`
-  - Runtime isolé des commits feature.
-
-- `6e1ba7e` — merge local dans `develop`.
-
-## QA verte
-
-Commandes QA finales validées:
-- `cargo fmt --all -- --check` OK.
-- `cargo test -p application --test workstate` OK, 21 passed, aucun warning Rust.
-- `cargo test -p app-tauri --test dto_agents` OK, 21 passed.
-- `cargo check -p app-tauri` OK.
-- `cd frontend && npx vitest run src/features/workstate/workstate.test.tsx src/features/projects/projects.test.tsx` OK, 2 files / 19 tests.
-- `cd frontend && npx tsc --noEmit` OK.
-
-Warnings restants uniquement côté Vite sur options `esbuild` dépréciées/ignorées au profit de `oxc`, non bloquants.
-
-## Décisions produit/techniques
-
-- Source primaire: handoff conversationnel existant.
-- Fallback: derniers tours bornés du log, jamais le log brut complet.
-- Read-only et best-effort: les erreurs de preview ne bloquent pas `live/busy/tickets`.
-- Pas de nouvelle persistance, pas de mutation/réparation, pas de nouvelle action UX.
-
-## Suite probable
-
-Le prochain lot logique est Lot D: actions UX read/write contrôlées autour du panneau Work (ouvrir/rattacher cellule, voir conversation, arrêter agent, éventuellement copier résumé), à cadrer par Architect avant implémentation.

.ideai/memory/checkpoint-workstate-delegation-queue-lot-b.md

@@ -1,62 +0,0 @@
----
-name: checkpoint-workstate-delegation-queue-lot-b
-description: memory note checkpoint-workstate-delegation-queue-lot-b
-metadata:
-  type: project
----
-# Checkpoint — Workstate delegation/queue snapshot Lot B
-
-Date: 2026-06-20
-
-## État final
-
-Lot B `workstate delegation/queue snapshot` terminé, validé QA et mergé localement dans `develop`.
-
-Branche finale:
-- `develop` @ `64c2c14` — merge local `feature/workstate-delegation-queue`.
-- `feature/workstate-delegation-queue` conservée.
-- Aucun push, aucune branche supprimée.
-- Working tree propre après décision Git.
-
-## Commits créés
-
-- `cc7d99a` — `feat(workstate): snapshot des délégations en file par agent (Lot B backend)`
-  - `QueuedTicketSnapshot` + port read-only `AgentQueueSnapshot`.
-  - Impl `InMemoryMailbox` snapshot FIFO sans cloner les senders.
-  - `GetProjectWorkState.agents[].tickets` avec statut dérivé `inProgress/queued`, source `human/agent`, preview bornée.
-  - DTO Tauri camelCase et wiring `AppState` avec le même mailbox partagé en deux ports.
-
-- `c600604` — `feat(workstate): UI des délégations en file par agent (Lot B frontend)`
-  - Types TS `AgentTicketState`, `TicketWorkStatus`, `TicketWorkSource`.
-  - Mock gateway normalise `tickets: []`.
-  - Panneau Work affiche les tickets FIFO, source Human/Agent, preview, ticket court.
-  - Refresh ajouté sur `delegationReady`.
-
-- `5cb99fd` — `chore(wip): état runtime .ideai (flux conversation live, layouts)`
-  - Runtime isolé des commits feature.
-
-- `64c2c14` — merge local dans `develop`.
-
-## QA verte
-
-Commandes QA réelles validées:
-- `cargo fmt --all -- --check` OK.
-- `cargo test -p infrastructure mailbox --lib` OK, 13 passed.
-- `cargo test -p application --test workstate` OK, 12 passed.
-- `cargo test -p app-tauri --test dto_agents` OK, 20 passed.
-- `cargo check -p app-tauri` OK.
-- `cd frontend && npx vitest run src/features/workstate/workstate.test.tsx src/features/projects/projects.test.tsx` OK, 2 files / 17 tests.
-- `cd frontend && npx tsc --noEmit` OK.
-- QA ajoutée: `cargo test -p domain mailbox --lib` OK, 6 passed.
-
-Warnings observés uniquement côté Vite sur options `esbuild` dépréciées/ignorées au profit de `oxc`, non bloquants.
-
-## Décisions produit/techniques
-
-- Les tickets `human` et `agent` sont inclus dans le snapshot; l'UI distingue explicitement `Human` vs agent/requester au lieu de tout appeler délégation agent.
-- Le statut est dérivé à la lecture: `inProgress` si le ticket courant correspond au `busy_state`, sinon `queued`.
-- Pas de nouvelle persistance, pas de lecture `log.jsonl`/handoff, pas d'événement `agentQueueChanged`, pas d'action UX d'annulation/résolution.
-
-## Suite probable
-
-Le prochain lot logique du chantier UX conversations/délégations est Lot C: résumés de conversations depuis log/handoff en lecture best-effort, ou Lot D actions UX selon priorité produit. Suivre le cycle Main: Architect -> Git -> DevBackend/DevFrontend -> QA -> Git.

.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/conversation-log-ls6-rotation-and-paginated-read.md

@@ -0,0 +1,29 @@
+---
+name: conversation-log-ls6-rotation-and-paginated-read
+description: Contrat figé de la rétention/rotation du transcript et de la lecture paginée riche (surface humaine).
+metadata:
+  type: reference
+---
+# LS6 — Rotation transcript + lecture paginée
+
+Hygiène de persistance du `log.jsonl` + surface de lecture humaine paginée (viewer LS7).
+
+## Invariant pivot INV-LS6
+La rotation n'élague/déplace JAMAIS un tour d'id ≥ `up_to` du handoff courant : le tour up_to + tous les postérieurs restent dans le segment ACTIF. Sans handoff (ou up_to nil) ⇒ aucune rotation. Garantit que `ConversationLog::read(since=up_to)` (fold incrémental) et la reprise restent corrects après rotation. Motif : `read(since)` cherche le curseur par position ; retirer up_to du fichier casserait le fold.
+
+## Rotation
+- Stratégie = **archive segmentée** (`log.jsonl` actif + `log.1.jsonl`… anciens), PAS troncature/suppression (transcript = surface humaine riche à préserver).
+- Déclencheur **hors chemin chaud** : use case `RotateConversationLog` à la reprise/ouverture, best-effort, idempotent. L'`append` ne déclenche JAMAIS la rotation (zéro latence ajoutée).
+- Seuils sur segment actif : `ROTATE_AFTER_TURNS=500` OU `ROTATE_AFTER_BYTES=1MiB`. Backstop disque `MAX_ARCHIVE_SEGMENTS=20` (drop du plus ancien seulement). Politique pure domaine `rotation_plan(...) -> Skip|Archive{keep_from=up_to}`.
+- Mécanique : verrou conversation bref ; réécriture actif **atomique en dernier** (tmp+rename) ; aucun tour perdu (∪ actif+archives) ; pagination dédoublonne par TurnId (crash-safe).
+
+## Lecture paginée (port ISP `ConversationArchive`, impl FsConversationLog)
+- `page(conversation, PageCursor{anchor,direction Forward|Backward}, limit)` → `TurnSlice{turns, has_more}`. limit clampé [1,200] défaut 50. Ordre chrono croissant. Archive-aware.
+- Use case `ReadConversationPage` → DTO humain `TurnPage{turns:[TurnView{id,at_ms,role,source,text COMPLET,text_len}], has_more, next_anchor}`. **Texte complet, non borné, non distillé** = surface HUMAINE.
+- `ConversationLog` (append/read/last) inchangé = vue segment actif (chemin chaud + dérivation).
+
+## Frontière
+Lecture riche consommée UNIQUEMENT par la commande Tauri du viewer humain, jamais par compose_convention_file/handoff/agent. Rotation ne touche que le transcript brut, jamais le handoff/injection.
+
+## Frontend
+LS6 = backend + commande Tauri `read_conversation_page`. Tout le React (viewer) = LS7.

.ideai/memory/conversation-viewer-ls7-frontend.md

@@ -0,0 +1,26 @@
+---
+name: conversation-viewer-ls7-frontend
+description: Contrat figé du viewer de transcript paginé (frontend pur, lecture seule, surface humaine).
+metadata:
+  type: reference
+---
+# LS7 — Viewer fil-par-paire (front pur)
+
+Dernier lot fonctionnel du programme persistance. UI humaine qui rejoue le transcript par paire, consomme la commande LS6 `read_conversation_page`. Lecture seule, zéro impact backend/agent.
+
+## Gateway / adapter / mock (patron WorkStateGateway)
+- Port `ConversationGateway.readPage(projectId, conversationId, {anchor?, direction?, limit?}) -> TurnPage`. Ajouter `conversation` à `Gateways`.
+- Types domaine : `TurnView{id, atMs, role: prompt|response|toolActivity, source: {kind:human}|{kind:agent,agentId}, text COMPLET, textLen}`, `TurnPage{turns, hasMore, nextAnchor}`.
+- Adapter `TauriConversationGateway` → invoke("read_conversation_page",{projectId,conversationId,cursor:{anchor,direction},limit}) + `conversationNormalization.ts` (mapper source Human/Agent calqué sur workStateNormalization). Mock avec pagination réelle + `_setTurns` pour tests offline.
+- Frontière : composant → useGateways().conversation → adapter → invoke. Jamais d'invoke direct.
+
+## Modèle d'affichage
+- Clé = conversationId. Entrée = drill-down depuis le Work panel (`ConversationWorkSummary.conversationId` déjà énuméré ; rendre les lignes cliquables via prop `onOpenConversation`). Pas de nouvel appel « liste conversations ».
+- Rejeu chrono croissant ; distinction sobre User↔Agent vs Agent↔Agent (parties déduites des sources, noms résolus depuis l'inventaire agents) ; toolActivity atténué/replié.
+- Pagination : ouverture backward/None = dernière page (bas du fil) ; scroll-up = backward ancré sur le tour le plus ANCIEN du buffer (préfixe, dédup par id, hasMore gate) ; refresh queue = forward ancré sur le plus récent (manuel ou sur domain events delegationReady/orchestratorRequestProcessed).
+
+## Intégration
+- État local `viewerConversationId` dans ProjectsView ; swap main-area (rend ConversationViewer à la place de LayoutGrid, PAS un nouveau kind backend) ; bouton retour ; reset au changement de projet. viewerConversationId=null ⇒ UI actuelle inchangée (non-régression terminal).
+
+## Frontière / backend
+Lecture seule (read_conversation_page LS6, hors chemin chaud), jamais injecté dans un contexte agent. **Aucune part backend** : juste vérifier la signature de la commande exposée et aligner l'adapter si écart.

.ideai/memory/develop-realigned-to-cli-ui-baseline-2026-07-02.md

@@ -0,0 +1,52 @@
+---
+name: develop-realigned-to-cli-ui-baseline-2026-07-02
+description: memory note develop-realigned-to-cli-ui-baseline-2026-07-02
+metadata:
+  type: project
+---
+# develop réaligné sur la ligne UI CLI (pre-chat-ui-baseline) — 2026-07-02
+
+**Type :** décision de topologie, validée utilisateur.
+
+## Contexte / erreur corrigée
+
+La feature « annonces inter-agent + fix Final Codex » avait été branchée par erreur sur
+`develop` @ `0072aff`, qui portait le chantier **canonical-conversation / chat** (LC1→LC5).
+Or l'UI de référence de l'utilisateur est la **ligne CLI** portée par
+`feature/pre-chat-ui-baseline` @ `a9653bc` (UI CLI + commit « délégation toujours headless,
+jamais d'injection PTY »). Le rebuild sur develop avait régressé l'UI (plus de terminaux CLI).
+De plus, `a9653bc` — prémisse runtime de l'overlay — n'était QUE sur pre-chat-ui-baseline.
+
+## Opération effectuée (Git, réversible, locale, aucune sortante)
+
+1. Secours du chantier chat : branche `snapshot/develop-canonical-conversation-0072aff` +
+   tag homonyme → `0072aff` (récupérable à 100%).
+2. `git branch -f develop feature/pre-chat-ui-baseline` → **develop == `a9653bc`** (arbre
+   exactement celui de la ligne CLI). Le chantier chat est SUPERSÉDÉ sur la mainline develop
+   mais non détruit.
+3. Nouvelle branche de fix : **`feature/inter-agent-announcements-v2`** depuis le nouveau
+   develop (@ a9653bc).
+
+Retour arrière : `git branch -f develop snapshot/develop-canonical-conversation-0072aff`.
+
+## État des refs
+
+- `develop` = `a9653bc` (base de travail canonique désormais = ligne CLI).
+- `feature/inter-agent-announcements-v2` = base de travail pour reporter les fix.
+- `feature/inter-agent-announcements` = `71d307d` : ancien commit B0-B3 (basé sur l'ancien
+  develop chat), conservé pour cherry-pick.
+- `snapshot/develop-canonical-conversation-0072aff` = chantier chat préservé.
+
+## Conséquences pour la suite
+
+- Reporter **B1/B2/B3** sur `feature/inter-agent-announcements-v2` (cherry-pick depuis
+  71d307d). **B0 devient probablement REDONDANT** : `a9653bc` (headless alongside/toujours
+  headless) est déjà la base — à vérifier avant de le rejouer.
+- **Re-planifier F1/F2/F3** : le design frontend (preview cellule demandeur + overlay cellule
+  cible) avait été cadré contre le modèle de cellules canonical-conversation de develop ; sur
+  la base CLI (`a9653bc`), il faut re-cibler le modèle de cellules CLI/PTY réel. À faire
+  cadrer par Architect avant dev frontend.
+- Rebuild AppImage à faire depuis cette base → restaure l'UI CLI + embarque les fix.
+
+Liens : [[inter-agent-announcements-feature-and-codex-final-bug]],
+[[inter-agent-live-context-shared-per-agent]].

.ideai/memory/f35-config-crud-delivered.md

@@ -0,0 +1,13 @@
+---
+name: f35-config-crud-delivered
+description: F35.2 (config serveur local + sélection dans les profils OpenCode) livrée et verte sur feature/modeles-locaux ; clôt le sprint modèles locaux F34-F36.
+metadata:
+  type: project
+---
+Ticket #35 F35.2 LIVRÉ (vert) sur `feature/modeles-locaux`. Débloqué par le contrat PLAT d'Architect.
+
+**Contrat backend** : `list_model_servers` / `save_model_server({request:{config}})` / `delete_model_server({serverId})`. DTO plat camelCase `LocalModelServerConfig { id, kind:"llamaCpp", name, baseURL, port, modelPath?, servedModelName, binaryPath?, args, autoStart, stopPolicy }`. PIÈGE intégré : `save_model_server` exige un UUID valide dans `config.id` même à la création (backend ne génère PAS l'id serveur, seulement le model.id interne caché) → le front minte l'UUID client-side (`newModelServerId`). Erreur suppression référencée = `code:"model_server_in_use"`.
+
+**Livré** : `ModelServerGateway` (port + adapter Tauri `adapters/modelServer.ts` + `MockModelServerGateway` avec `markInUse`). Feature `features/model-servers/` : `useModelServers` (CRUD, traduit in-use en message FR actionnable), `ModelServersPanel` (déclarer/éditer/supprimer), `ModelServerSelect` (dropdown binding avec « None » = serveur externe + préserve un id orphelin « unknown/removed »). Dans `FirstRunWizard`, le champ texte `localModelServerId` (F36) est remplacé par `ModelServerSelect`.
+
+Cohérent avec F35.1 (badge corrèle via localModelServerId). tsc 0 ; suite 608/608. Sprint modèles locaux (F34 backend, F35, F36) désormais complet côté frontend.

.ideai/memory/f36-multi-opencode-profiles-frontend.md

@@ -0,0 +1,17 @@
+---
+name: f36-multi-opencode-profiles-frontend
+description: Multiplicité des profils OpenCode locaux côté UI first-run wizard — livrée, verte, sans gap backend.
+metadata:
+  type: project
+---
+Ticket #36 (F36.1) livré côté frontend sur `feature/modeles-locaux`.
+
+**Constat clé** : aucun gap backend. Le backend supporte déjà N profils OpenCode (identité = ProfileId) via `clone_opencode_profile_from_seed`, `list_profiles`, `save_profile`, `delete_profile`, `configure_profiles`. `OpenCodeConfig` DTO expose `localModelServerId` (camelCase).
+
+**Ce qui manquait, purement front** : la commande clone n'était câblée dans aucun gateway, et le miroir TS `OpenCodeConfig` n'avait pas `localModelServerId`.
+
+**Livré** : `ProfileGateway.cloneOpenCodeProfileFromSeed` (port + adapter Tauri + mock) ; le first-run wizard (`FirstRunWizard.tsx` + `useFirstRun.ts`) gère désormais une LISTE de profils OpenCode — bouton "Add OpenCode profile" + "Duplicate" par ligne, name éditable, cases reasoning/attachment, champ localModelServerId (saisie simple).
+
+**Reste** : lot F35 = UI riche de config serveur local (remplacera la saisie simple de `localModelServerId`). Le wizard reste la surface de gestion de profils (`Settings ▸ Configure profiles` = `forceOpen`) ; il lit `firstRunState().referenceProfiles`, pas `list_profiles` — à vérifier au lot F35 pour l'édition de profils OpenCode déjà persistés.
+
+tsc propre ; 62 tests first-run/mock verts ; suite complète 581/581.

.ideai/memory/floatingwindow-focus-trap-mount-only.md

@@ -0,0 +1,11 @@
+---
+name: floatingwindow-focus-trap-mount-only
+description: Le focus-trap de FloatingWindow ne doit dépendre que du mount ; sinon un onClose instable vole le focus à chaque frappe.
+metadata:
+  type: reference
+---
+Le primitif `frontend/src/shared/ui/FloatingWindow.tsx` a un `useEffect` focus-trap qui appelle `(first ?? node)?.focus()`. Sa dépendance doit rester `[]` (mount-only), et `onClose` doit être lu via un `onCloseRef` maintenu à jour.
+
+**Pourquoi** : les appelants (ex. `TicketDetail.requestClose`) passent souvent un `onClose` recréé à chaque render. Si l'effet dépend de `[onClose]`, chaque frappe dans un input contrôlé de la fenêtre → re-render → nouvelle identité `onClose` → l'effet se ré-arme → focus renvoyé au premier focusable → l'utilisateur ne peut taper qu'UNE lettre à la fois (bug #17, corrigé 2026-07-07).
+
+**Comment l'appliquer** : ne jamais remettre `onClose` (ni une autre prop changeante) dans les deps de cet effet ; router les callbacks via une ref. Régression couverte par le test « #17 focus-loss bug » dans FloatingWindow.test.tsx. Voir [[ticket16-menus-floating-delivered-devfrontend]].

.ideai/memory/frontend-uses-npm-not-pnpm.md

@@ -0,0 +1,14 @@
+---
+name: frontend-uses-npm-not-pnpm
+description: memory note frontend-uses-npm-not-pnpm
+metadata:
+  type: project
+---
+Le dossier `frontend/` s'installe et se build avec **npm**, jamais pnpm (lockfile `package-lock.json`).
+
+**Ne jamais lancer `pnpm` (ni `corepack pnpm build`, ni le wrapper `pnpm --dir frontend build`) dans `frontend/`** :
+- `pnpm --dir frontend build` échoue d'abord sur un pré-check `pnpm install` (`ERR_PNPM_IGNORED_BUILDS` sur esbuild).
+- Surtout, `pnpm install` **clobber** le `node_modules` npm : pnpm aplatit `vite@5.4.21` au top-level alors que `vitest@4.1.x` exige `vite ^6||^7||^8`. Résultat : `ERR_PACKAGE_PATH_NOT_EXPORTED: './module-runner'` dès que vitest spawn son worker pool (>3 fichiers de test). Avec npm, `vite@8` est imbriqué sous `node_modules/vitest/node_modules/vite`, donc tout marche.
+- Réparation si le clobber arrive : `rm -f frontend/pnpm-lock.yaml frontend/pnpm-workspace.yaml && cd frontend && npm install`, puis `git checkout -- frontend/package-lock.json`.
+
+Commandes correctes sans le wrapper cassé : `cd frontend && npx tsc --noEmit && npx vite build` (build) et `npx vitest run` (tests). Le script `pnpm build` du package.json ne doit pas être utilisé tel quel dans cet environnement.

.ideai/memory/git-agent-push-access-gitea-ssh.md

@@ -0,0 +1,15 @@
+---
+name: git-agent-push-access-gitea-ssh
+description: memory note git-agent-push-access-gitea-ssh
+metadata:
+  type: project
+---
+**CORRECTION (2026-06-23) — annule et remplace la note précédente : l'agent Git N'A PLUS l'accès push. Il est de nouveau STRICTEMENT LOCAL, comme avant.**
+
+- Git gère **100 % du dépôt local** : commits, branches, merges/rebases locaux. Rien d'autre.
+- **Aucune action sortante** : pas de `git push`, pas de PR distante, pas de publication de tags, pas de synchronisation remote. Ce périmètre n'est PAS dans ses responsabilités.
+- Toute synchro avec un remote (`origin` Gitea ou autre) reste **hors périmètre Git** et sous décision/validation explicite de l'utilisateur, exécutée hors agent Git.
+
+Le contexte d'agent `git.md` reflète déjà ce retour au strictement-local (garde-fou « tu restes strictement local, pas de `git push` »).
+
+Voir [[git-owns-commit-merge-decisions]] (Git tranche toute la topologie LOCALE du dépôt).

.ideai/memory/handoff-ls5-summary-bound-and-llm-seam.md

@@ -0,0 +1,22 @@
+---
+name: handoff-ls5-summary-bound-and-llm-seam
+description: Contrat figé de la borne de handoff (perf) et du seam résumeur LLM non activé.
+metadata:
+  type: reference
+---
+# LS5 — Borne handoff + seam LLM
+
+Ferme le must-have perf du programme persistance : un `summary_md` non borné gonflait le contexte injecté à chaque lancement.
+
+## Borne summary_md (déterministe, en CARACTÈRES, pas tokens)
+- **Par tour** : `render_turn` tronque le texte aplati à `TURN_LINE_MAX_CHARS=240` (infra summarizer). Corrige le trou réel (un gros Response = ligne géante).
+- **Totale** : fn PURE domaine `bound_handoff_summary(Handoff, max)` + `HANDOFF_SUMMARY_MAX_CHARS=4096`. Stratégie de dépassement = **troncature distillée** (garde objectif + lignes les plus récentes, drop oldest, frontière de ligne). JAMAIS re-fold compactant, JAMAIS rejet (n'bloque jamais l'append du log). `up_to`/`objective` jamais modifiés. Idempotent.
+- **Appliquée à l'écriture** (`RecordTurn` après `fold`, avant `save` → borne universelle quel que soit le résumeur) **ET défensivement à l'injection** (`resolve_handoff` avant compose → protège les `handoff.md` legacy non bornés, sans migration).
+
+## Seam LLM : TRANCHÉ = « prêt mais NON activé »
+- Pas de vrai LLM en LS5 : `fold` tourne sur le chemin chaud (par tour, dans la délégation) → un appel réseau là = régression perf interdite. Défaut runtime reste `HeuristicHandoffSummarizer`.
+- Durcissement réel = la borne totale appliquée **dans RecordTurn (hors résumeur)** ⇒ un futur `LlmHandoffSummarizer` ne peut pas exploser le budget contexte.
+- Contrat futur adapter LLM (documenté) : déclenchement **froid/hors chemin** (reprise/rotation/débounce, jamais par tour) ; timeout + **fallback heuristique** (trait sans `Result`) ; sélection par flag, défaut heuristique. Trait `HandoffSummarizer::fold` inchangé.
+
+## Frontière
+Transcript = `log.jsonl` (jamais injecté). `summary_md` = dérivé distillé, désormais borné à l'écriture et à l'injection. Conforme « surface agent = borné/distillé ».

.ideai/memory/headless-interagent-conversation-objective.md

@@ -0,0 +1,40 @@
+---
+name: headless-interagent-conversation-objective
+description: memory note headless-interagent-conversation-objective
+metadata:
+  type: project
+---
+# Objectif chantier — remplacer la conversation inter-agent MCP par headless robuste
+
+## Intention produit
+
+Le projet veut se séparer du MCP pour la **conversation inter-agent**, car le rendez-vous MCP a provoqué trop de blocages, wedges, busy fantômes et pertes de résultats. MCP reste conservé pour les autres outils IdeA : mémoire, liste d'agents, contexte, workstate et fonctions non conversationnelles.
+
+Le nouveau mécanisme doit utiliser les modes **headless** fournis par les modèles/CLIs comme interface de communication entre agents, tout en gardant le modèle mental : **1 agent = 1 employé**.
+
+## Règles fonctionnelles validées
+
+- Un agent n'a qu'une seule conversation canonique et une seule identité opérationnelle, qu'il soit utilisé via la cellule CLI par l'utilisateur ou via headless par un autre agent.
+- Quand un agent B travaille pour un agent A, aucun autre agent ni l'utilisateur ne peut lui parler tant que B n'a pas fini.
+- L'utilisateur doit pouvoir voir que B est occupé et, si possible, suivre le travail headless en temps réel. La solidité prime sur cette UI temps réel.
+- L'utilisateur doit pouvoir cancel le travail d'un agent occupé.
+- Si l'utilisateur annule A dans la CLI alors que A attend B, l'annulation doit cascader vers B.
+- B ne peut être annulé que par l'agent qui lui parle ou par l'utilisateur, pas par un autre agent tiers.
+- Si plusieurs agents veulent parler à B, les demandes attendent en FIFO simple jusqu'à ce que B soit libre.
+- Le headless est seulement l'interface de communication agent-agent : mêmes mémoire, contexte, historique, permissions, cwd et outils qu'en usage CLI interactif.
+- Un historique reconstitué doit être accessible depuis la cellule, via un bouton, avec toutes les conversations de la session dans un historique unique.
+- L'architecture reste hexagonale : conversation canonique par modèle/adapters, pas de dépendance directe dispersée aux formats natifs.
+
+## Priorité de conception
+
+Priorité 1 : robustesse et absence de blocage durable.
+
+Le design doit privilégier des garanties mécaniques simples : processus headless borné, fin par exit process, timeout, cancel explicite, nettoyage d'état idempotent, queue FIFO observable, et résultat synthétique en cas d'échec.
+
+Priorité 2 : observabilité et UX.
+
+L'affichage temps réel du travail headless est souhaité si le mode headless permet de streamer stdout/stderr ou événements structurés, mais ne doit pas fragiliser le protocole. À défaut, fournir statut occupé, bouton cancel, historique final et diagnostic exploitable.
+
+## Décision de périmètre
+
+Le MCP n'est pas retiré globalement. Il est retiré uniquement du chemin critique de conversation inter-agent. Les outils IdeA existants peuvent rester exposés aux agents via MCP tant qu'ils ne servent pas au rendez-vous conversationnel.

.ideai/memory/idea-distribution-strategy-desktop-vs-docker.md

@@ -0,0 +1,19 @@
+---
+name: idea-distribution-strategy-desktop-vs-docker
+description: memory note idea-distribution-strategy-desktop-vs-docker
+metadata:
+  type: project
+---
+Stratégie de distribution IdeA validée utilisateur (2026-07-16, suite #13) : DEUX offres au-dessus du MÊME cœur backend (pas de fork métier).
+
+**Offre 1 — Full desktop** : binaire Tauri `app-tauri` actuel. AppImage Linux (existe, inchangée). Windows explicitement REPORTÉ (garder la portabilité à l'esprit, ne rien introduire de non-portable ; PTY = ConPTY à retester le jour venu). L'AppImage reste desktop PUR — elle ne bundle pas les assets web.
+
+**Offre 2 — Serveur/client** : image Docker, bâtie sur un binaire serveur HEADLESS `idea-serve` SANS dépendance Tauri/WebKit (pas de dockerisation du binaire Tauri qui traînerait GTK/WebKit pour rien). Cadré faisable en hexagonal par Architect.
+
+**Point pivot technique** : `server.rs` vit dans `crates/app-tauri` et réutilise indirectement la présentation Tauri via `crate::state::AppState`, `crate::dto::*`, `crate::events::DomainEventDto`, `crate::pty::PtyChunk`, `crate::mcp_endpoint::*`, `ResumeContext`. Le protocole HTTP/WS lui est déjà autonome. Le vrai travail = découpler les DTO (→ crate partagé `presentation-dto`/`backend-api`) puis extraire `crates/web-server` (sur `BackendCore`, pas `AppState`) puis le bin `idea-serve`.
+
+**Tickets** : #65 (headless, high, L1 DTO→L2 web-server→L3 idea-serve), #66 (Docker, medium, L4 build web http→L5 Dockerfile volumes /data+/workspace→L6 agents CLI conteneur), #64 (folder browser web, dependsOn #66 pour /workspace), #67 (lock inter-process app-data-dir, low).
+
+**Topologie de branches (décision utilisateur)** : chantier packaging sur `feature/server-client-packaging` (créée depuis `c246875`, tête de `feature/ticket13-pty-websocket`). PAS de merge dans develop tant que l'utilisateur n'a pas validé lui-même la NON-RÉGRESSION desktop-only. Flux final : `feature/server-client-packaging` → `feature/ticket13-pty-websocket` → `develop`. Git rebase la branche packaging si #13 avance.
+
+Invariants : desktop AppImage ne perd RIEN ; aucun import Tauri dans le bin headless ; même cœur/use cases/stores ; contrat HTTP/WS inchangé sauf lot versionné. Voir [[frontend-uses-npm-not-pnpm]], [[appimage-build-no-strip-relr-dyn-fix]].

.ideai/memory/idea-program-surface-separation-and-livestate.md

@@ -0,0 +1,14 @@
+---
+name: idea-program-surface-separation-and-livestate
+description: Cadrage du programme post-skills : ce qui existe vs reste, et la règle de frontière surface-agent/humaine.
+metadata:
+  type: project
+---
+État au cadrage (develop @ 827d477) :
+- **#2a handoff incrémental cross-profile = FAIT + CÂBLÉ** (lots P1–P8) : `domain/conversation_log.rs` (`Handoff`, `HandoffStore`, `HandoffSummarizer::fold` incrémental, `ProviderSessionStore`), `application/conversation/record.rs` (`RecordTurn` = append+fold), wiring `state.rs` (`AppRecordTurnProvider`), injection au lancement via `HandoffProvider` (P7). Résumeur = `HeuristicHandoffSummarizer`, seam async pour `LlmHandoffSummarizer` (P10) déjà en place. Reste : seam LLM + borne `summary_md`.
+- **#2b log canonique = FAIT** : `ConversationLog` append-only `.ideai/conversations/<id>/log.jsonl`, **jamais injecté à un agent** (doc domaine explicite). Reste : rétention/rotation + lecture paginée UI.
+- **#1 live-state agent = À CONSTRUIRE (cœur)** : aujourd'hui seul `GetProjectWorkState` (read-model HUMAIN dérivé, non durable). Construire un 4ᵉ store `live-state.json` (**gitignored, runtime**) : `domain/live_state.rs` (`LiveState`/`LiveEntry`/`WorkStatus`, port `LiveStateStore`, **keyed last-writer-wins, JAMAIS append**, champs bornés, `prune` TTL+max_n), use cases `UpdateLiveState`/`GetLiveStateLean`, adapter `FsLiveStateStore`, auto-update depuis `orchestrator/service.rs` (ask→Working, reply→Done), injection bornée `# État du projet` au lancement + outils MCP `idea_workstate_read`/`idea_workstate_set`. Ne stocke QUE le non-re-dérivable (intent/progrès/dernière délégation) ; busy/queue restent calculés.
+
+**Règle de frontière gravée (testable)** : Surface AGENT = borné/distillé/pointeur uniquement (capacités, pointeurs mémoire, affordances skills, handoff `summary_md`, live-state lean). Surface HUMAINE = riche (ProjectWorkStatePanel, viewer fil-par-paire qui rejoue le log). **Transcript / append-only INTERDIT d'injection dans un contexte agent** ; seul un dérivé distillé franchit. 4 stores distincts : `memory/` (savoir stable, versionné) · `handoff.md` (reprise par fil) · `log.jsonl` (transcript humain) · `live-state.json` (coordination transitoire maigre).
+
+Découpage : LS0 doc baseline → LS1 domaine live-state → LS2 store+usecases → LS3 auto-update délégation → LS4 injection+MCP (clôt cold-start) ; LS5 seam LLM+borne handoff, LS6 rétention log+lecture UI (parallèles) ; LS7 UX fil-par-paire (front pur) ; LS8 doc clôture.

.ideai/memory/inter-agent-announcements-feature-and-codex-final-bug.md

@@ -0,0 +1,67 @@
+---
+name: inter-agent-announcements-feature-and-codex-final-bug
+description: memory note inter-agent-announcements-feature-and-codex-final-bug
+metadata:
+  type: project
+---
+# Annonces inter-agent (UI live) + fix du Final Codex — DESIGN FIGÉ
+
+**Type :** design de feature + bug racine. Validé utilisateur le 2026-07-02, cadré par Architect.
+
+## Bug racine (Codex)
+
+`crates/infrastructure/src/session/codex.rs` : `parse_event` (~l.86) mappe CHAQUE
+`item.completed{item.type=="agent_message"}` vers `ReplyEvent::Final`, et `send` (~l.234)
+casse au PREMIER Final (`break 'lines`). Or `codex exec --json` émet plusieurs
+`agent_message` par tour (préambule → outils → conclusion → `turn.completed`). IdeA
+renvoyait donc le **préambule** au demandeur au lieu de la **conclusion**. Preuve live :
+Architect répondait « je vais interroger QA… » au lieu du résultat. **Défaut d'implémentation,
+pas du headless Codex** (un `codex exec` brut déroule tout le tour).
+
+## Feature validée (le bug devient fonctionnalité)
+
+- **Final** = DERNIER `agent_message` avant `turn.completed` → seule chose renvoyée au
+  demandeur (résout le ticket). Bords : 1 seul message (préambule=conclusion) ; 0 message
+  → `TargetReturnedNoReply` (inchangé).
+- **Annonces** = `agent_message` intermédiaires → nouvel événement NON terminal
+  `ReplyEvent::Announcement{text}`, poussé sur le bus vers l'UI, JAMAIS renvoyé au
+  demandeur, JAMAIS persisté au transcript (éphémère).
+- **UI** : (a) cellule DEMANDEUR = petit cadre preview près de la drop-list d'agents,
+  filtré par `ticket_id` ; (b) cellule CIBLE si visible = overlay d'indisponibilité (texte
+  haut « un agent est en train de lui parler » + annonces défilantes au centre), monté sur
+  live-state Working, retiré au Final/idle (reste tant qu'≥1 ticket actif sur la cible).
+
+## Contrat (Architect)
+
+- `ReplyEvent::Announcement{text}` (non terminal) vs `Final{text}` (terminal, résout).
+- `drain_with_readiness` : Announcement → publie event, ne résout pas, ne passe pas idle ;
+  Final → résout ticket + idle + fin du drain.
+- Nouveau `DomainEvent::AgentAnnouncement{project_id, requester, target, ticket_id, text,
+  at_ms}` (attribution obligatoire pour router vers la bonne cellule + isoler projet/onglet).
+- Overlay cible = état UI piloté par live-state (pas un blocage du PTY : le contact passe par
+  session headless séparée, `allow_structured_alongside_pty:true`).
+- Généralisation Claude : `session/claude.rs` garde son terminal explicite (`result`) comme
+  Final ; messages complets non terminaux → Announcement ; NE PAS promouvoir les `TextDelta`
+  tokenisés (bruit) ; tool events restent `ToolActivity`.
+
+## Découpage dev (Architect)
+
+- **B1** domaine/appli : `ReplyEvent::Announcement`, `DomainEvent::AgentAnnouncement`,
+  `structured.rs`, `service.rs` (`ask_structured` ne termine que sur Final).
+- **B2** Codex `codex.rs` : bufferiser le dernier `agent_message`, émettre les précédents en
+  Announcement, le dernier en Final à `turn.completed`.
+- **B3** Tauri `app-tauri/{events,dto,state}.rs` : relay + DTO camelCase.
+- **F1** front store/gateway annonces (index par ticket/target, borné ~20-50).
+- **F2** front preview cellule demandeur.
+- **F3** front overlay cellule cible.
+- **Q** QA e2e : Main→Architect→QA, préambule+outil+conclusion ; Main ne reçoit que la
+  conclusion ; preview demandeur + overlay cible pendant le travail ; fermeture au Final.
+  Critère : reproduire le bug initial et constater la correction.
+
+## État
+
+Design figé, cadrage Architect complet. Reste : Git branche → B1/B2/B3 + F1/F2/F3 → QA.
+Non démarré côté dev au 2026-07-02.
+
+Liens : [[inter-agent-live-context-shared-per-agent]], [[rendezvous-no-reply-backstop-design]],
+[[headless-interagent-conversation-objective]], [[conversation-viewer-ls7-frontend]].

.ideai/memory/inter-agent-live-context-shared-per-agent.md

@@ -0,0 +1,79 @@
+---
+name: inter-agent-live-context-shared-per-agent
+description: memory note inter-agent-live-context-shared-per-agent
+metadata:
+  type: project
+---
+# Contexte live inter-agent : PAR AGENT (partagé), pas par paire — DÉCISION FIGÉE
+
+**Type :** decision d'architecture / produit — validée utilisateur le 2026-07-02.
+
+## Décision
+
+Le contexte live d'un agent IdeA est porté **par l'agent cible**, partagé entre TOUS les
+demandeurs. Pour un `AgentId` donné, IdeA maintient **au plus une** session
+headless/structurée vivante ; tous les `idea_ask_agent(requester, target)` vers le même
+`target` réutilisent cette session, quel que soit le demandeur.
+
+Ce partage est **intentionnel et souhaité**, pas un bug ni une fuite : tous les agents du
+projet sont dans le même domaine de confiance (même utilisateur, même projet). Le contexte
+live d'un agent = mémoire de travail d'équipe / tableau blanc partagé. On NE veut PAS
+d'isolation par paire.
+
+La paire `(requester, target)` n'est **pas** une frontière d'isolation du contexte moteur :
+elle sert uniquement à l'attribution, la corrélation requête/réponse, les vues UI et les
+filtres de transcript.
+
+## Preuve empirique (2026-07-02)
+
+Main a confié à QA le token `IDEA-TOKEN-7F3A-BLEEDCHECK` ; Architect a ensuite pu le
+récupérer auprès de QA **sans que Main le lui transmette**. Cause : `ensure_structured_session`
+(`crates/application/src/orchestrator/service.rs:1948`) fait un early-return sur
+`session_for_agent(&agent_id)` → une seule session vivante par agent, réutilisée.
+
+## Modèle de transcript cible (cadré par Architect)
+
+**Log canonique PAR AGENT + vues par paire dérivées.** Abandon du transcript canonique
+par paire comme source de vérité (il promet une isolation qui n'existe pas en live).
+
+- Arbo cible : `.ideai/conversations/agents/<targetAgentId>/{log.jsonl, handoff.md, providers.json, log.N.jsonl}`
+- Chaque tour porte l'attribution : `thread_id=Agent(target)`, `requester`, `target`,
+  `correlation_id`, `role`, `source`.
+- Vues = projections filtrées (`ForAgent`, `ForPair`, `ForCorrelation`), pas des logs séparés.
+
+Impacts à traiter :
+- `resolve_conversation` → `resolve_agent_thread(target)` + `resolve_conversation_view(requester,target)`.
+- `bind_conversation_session` → bind sur `targetAgentId` ; réutiliser la session existante.
+- `ConversationRegistry` → index primaire `targetAgentId`, secondaires `requester`/`correlation_id` ;
+  interdire 2 fils live pour le même target.
+- `ProviderSessionStore` clé `(agent_thread_id, provider_id)` au lieu de `(pair_id, provider_id)`.
+- `LeafCell.conversation_id` = désormais **id de fil agent**, plus « id de paire ».
+- Viewer LS7 : défaut = fil agent complet ; vue par paire = vue filtrée/partielle libellée comme telle.
+
+## Garde-fou efficience (rotation multi-demandeurs)
+
+Le design LS5/LS6 tient, mais un fil agent partagé **croît plus vite** (agrège les demandes
+de plusieurs requesters). Ajustements : la rotation s'applique au fil agent canonique (pas
+aux vues) ; le résumé/handoff doit conserver l'attribution minimale (`Objectif courant`,
+`Demandes actives par requester`, `Décisions récentes`, `Blocages`, `Dernière réponse
+corrélée`) ; transcript brut jamais réinjecté (humain-only) ; handoff borné à
+`HANDOFF_SUMMARY_MAX_CHARS=4096`. Risque principal : dilution si demandeurs poussent des
+objectifs contradictoires → mitigé par les rubriques stables du handoff.
+
+## Découpage dev recommandé (Architect)
+
+1. `ARCHITECTURE.md` §19.7 : remplacer « id de paire » par « fil agent partagé » (+ §16/§17/§21).
+2. Introduire `ConversationThreadId` / `ConversationViewId`.
+3. Adapter `resolve_conversation`, `bind_conversation_session`, `ConversationRegistry`.
+4. Compatibiliser les anciens chemins `for_pair(requester,target)` comme vues historiques.
+5. LS7 viewer : fil agent complet + filtres.
+6. Test QA : un fait confié à QA par Main est visible quand Architect interroge QA.
+
+## État
+
+Décision figée. Cadrage architectural livré par Architect. Reste à : intégrer la proposition
+dans `ARCHITECTURE.md`, puis planifier le dev (cycle normal Architect→Git→Dev→QA).
+
+Liens : [[conversation-rotation-safety-design]], [[handoff-ls5-summary-bound-and-llm-seam]],
+[[conversation-log-ls6-rotation-and-paginated-read]], [[conversation-viewer-ls7-frontend]],
+[[headless-interagent-conversation-objective]].

.ideai/memory/issue-ticket-system-design.md

@@ -0,0 +1,78 @@
+---
+name: issue-ticket-system-design
+description: memory note issue-ticket-system-design
+metadata:
+  type: project
+---
+---
+name: issue-ticket-system-design
+description: Cadrage figé (Architect+Main, 2026-07-02) du système de tickets IdeA façon Jira — domaine `Issue` par projet, exposé « ticket » côté UI/MCP, Carnet éditable, #N séquentiel. Fait autorité pour les lots T1-T6/F1-F7.
+metadata:
+  type: reference
+---
+# Système de tickets IdeA (domaine `Issue`) — CADRAGE FIGÉ 2026-07-02
+
+## Décisions produit verrouillées (utilisateur)
+- **Portée PAR PROJET** : stockage dans `.ideai/tickets/` du projet (pas de backlog global).
+- **Identifiant court `#42`** : compteur séquentiel par projet, parlable à l'oral (poignée
+  partagée humain↔agent, y compris dans une délégation `idea_ask_agent`).
+- **Champ de connaissances éditable = « Carnet »** (PAS « mémoire » — évite collision avec la
+  mémoire projet). Markdown éditable/réorganisable, scoped ticket, pas append-only.
+- **Stockage Markdown + frontmatter**, un DOSSIER par ticket.
+- **V1 SANS attachments** : livrer T1-T5 + F1-F5 + F7 ; attachments (T6/F6) en fast-follow.
+
+## Nommage (collision évitée avec le TicketId de délégation)
+Domaine/code = **`Issue`** (`IssueId`, `IssueNumber`, `IssueRef("#42")`, `IssueStore`,
+modules `domain::issue`/`application::issues`/`infrastructure::issues`). UI + MCP public =
+« ticket » (`idea_ticket_*`, DTO camelCase). Ne JAMAIS nommer `Ticket` en code (réservé à la
+délégation inter-agent).
+
+## Frontière Carnet vs mémoire projet
+Carnet = savoir DU ticket (décisions locales, hypothèses, investigation, contraintes). Mémoire
+projet = savoir transverse durable. Règle : si l'info doit survivre à la fermeture du ticket et
+guider d'autres travaux → mémoire projet ; sinon → carnet.
+
+## Modèle domaine
+`Issue { id(uuid), number(u64), title, description(md), status, priority, carnet, links,
+agent_refs, attachments, created_by/updated_by(IssueActor: User|Agent|System),
+created_at/updated_at, version(optimistic) }`.
+- `IssueStatus`: Open | InProgress | Qa | Closed (DTO: open|inProgress|QA|closed).
+- `IssuePriority`: Low | Medium | High | Critical.
+- `IssueLinkKind`: RelatesTo | Blocks | BlockedBy | Duplicates | DependsOn.
+- `AgentIssueRef { agent_id, role: Assigned|Mentioned|Reviewer|Owner }`.
+Invariants : number>0 unique/projet ; IssueRef = `#<u64>` ; titre non vide ; pas de self-link ;
+assignation → AgentId connu du manifeste ; toute écriture incrémente version ; attachments sous
+le dossier du ticket, pas de `..`/symlink/chemin absolu.
+
+## Ports
+`IssueStore` (create/get_by_ref/list(filter)/update(expected_version)/read_carnet/
+write_carnet(expected_version)) ; `IssueNumberAllocator` (allocate_next, atomique via
+counter.json + counter.lock + rename, jamais de réutilisation de numéro) ; `IssueAttachmentStore`
+(add/remove/list — lot attachments). Adapters : `FsIssueStore`, `FsIssueNumberAllocator`,
+`FsIssueAttachmentStore`, `McpIssueTools`, `TauriIssueCommands`, `TauriIssueEventRelay`.
+
+## Surface MCP (agents)
+`idea_ticket_create/read/list/update/update_status/update_priority/read_carnet/update_carnet/
+link/unlink` (+ `idea_ticket_attachment_*` au lot attachments). DTO camelCase ; `TicketRef` =
+`#${number}` ; concurrence via `expectedVersion` sur chaque écriture.
+
+## Events domaine (→ projection UI, même modèle events→front B-series)
+IssueCreated/Updated/StatusChanged/PriorityChanged/CarnetUpdated/Linked/Unlinked/
+AgentAssigned/AgentUnassigned/AttachmentAdded/Removed/StorageConflictDetected.
+
+## Layout stockage
+`.ideai/tickets/{counter.json, index.json(projection reconstructible), <N>/{issue.md(frontmatter
++description), carnet.md, attachments/}}`. Attachments versionnés git par défaut (warning >5MiB,
+refus configurable >25MiB, pointeur URI pour les gros).
+
+## Lots
+Backend : T1 domaine Issue · T2 store FS Markdown (+allocator) · T3 use cases (Create/Read/List/
+Update/UpdateCarnet/Link/AssignAgent, optimistic concurrency) · T4 surface MCP `idea_ticket_*` ·
+T5 commands Tauri + relay events · T6 attachments (fast-follow).
+Frontend : F1 gateway UI (`IssueGateway`, pas d'invoke direct) · F2 liste filtrable · F3 détail/
+édition (gestion conflits expectedVersion) · F4 éditeur Carnet Markdown · F5 liens & assignations ·
+F6 attachments (fast-follow) · F7 `#42` cliquable + pré-remplissage délégation.
+Réutilise : store FS par projet façon `FsBackgroundTaskStore`/`AppLiveStateProvider`, EventBus +
+TauriEventRelay, pattern gateway UI.
+
+Lien : [[background-tasks-first-class-design]], [[agent-context-memory-and-profile-handoff]].

.ideai/memory/live-state-persistence-program-closed-ls8.md

@@ -0,0 +1,15 @@
+---
+name: live-state-persistence-program-closed-ls8
+description: Le programme live-state + persistance conversationnelle est livré et documenté ; pointe la doc de clôture et les points restés ouverts.
+metadata:
+  type: project
+---
+Programme **live-state / persistance conversationnelle CLOS** (LS1→LS7 livrés @ fd7adbb ; LS8 = doc de clôture).
+
+**Doc de référence** : `docs/LS8-live-state-persistence-closure.md` + `ARCHITECTURE.md` §21 (cartographie des 4 stores) ; §19 retitré « LIVRÉ » ; §14.1 et §18.5 corrigés (catalogue MCP **14**).
+
+**4 stores disjoints** : `.ideai/memory/` (savoir stable, versionné) · `handoff.md` (reprise distillée bornée ≤4096) · `log.jsonl` (transcript humain riche, JAMAIS injecté) · `live-state.json` (coordination maigre runtime, gitignoré). Surface AGENT bornée/distillée/pointeur ; surface HUMAINE riche ; seul le handoff distillé franchit vers un contexte agent.
+
+**Restant ouvert** : (1) activation seam LLM `LlmHandoffSummarizer` (non activé, défaut heuristique, contrat ADR LS5) ; (2) sweep périodique de rotation (idempotent, non câblé) ; (3) **discordance D19-4 ↔ .gitignore** : `.ideai/conversations/` devait être gitignoré mais est suivi — à trancher Git/Main ; (4) intégration MCP e2e UX ; (5) multi-fenêtres registre sessions ; (6) auto-update mémoire/contexte en cours de session.
+
+**Contrainte d'écriture** : un agent lancé en run-dir isolé (`.ideai/run/<id>/`) **ne peut pas écrire l'arbre du project root** (ARCHITECTURE.md, docs/) — les modifs de doc passent par Git (write+commit authority).

.ideai/memory/live-state-reboot-reconciliation-design.md

@@ -0,0 +1,21 @@
+---
+name: live-state-reboot-reconciliation-design
+description: memory note live-state-reboot-reconciliation-design
+metadata:
+  type: project
+---
+---
+title: Réconciliation du live-state au reboot (ReconcileLiveState)
+type: reference
+description: Décision d'architecture pour réconcilier les lignes live-state fantômes au redémarrage — seam, source de vérité, contrat de statut et préservation du self-only.
+---
+**Problème** : au reboot, `.ideai/live-state.json` n'est pas réconcilié → agents fantômes `working/waiting/blocked` alors que leurs sessions sont mortes. `prune` (TTL 6h) ne couvre pas le fantôme récent.
+
+**Décision (cadrage Architect, 2026-06-23)** :
+- **Seam** : étape best-effort `reconcile_live_state` dans la chaîne `open_project` (commands.rs), juste après `reconcile_layouts`. Pas d'app-boot global (live-state est par-projet). Pas d'outil MCP. Justification : un crash ne déclenche jamais `close_project`, donc **open est le seul filet fiable**.
+- **Source de vérité** : le registre de sessions vivantes `LiveSessions` / trait `LiveAgentRegistry` (`application/src/terminal/registry.rs`) — la *même* vérité que `GetProjectWorkState`. Prédicat orphelin = `status ∈ {working,waiting,blocked}` ET `!is_agent_live`. Race-safe : tourne avant toute relance ; LWW gagne via `updated_at_ms` frais.
+- **Contrat** : orphelin → `idle` (pas de nouveau statut, évite le ripple DTO/front). Garder `intent` (trace), vider `ticket` + `last_delegation` (rendez-vous mort, tracé ailleurs dans log/handoff), `progress` = marqueur stale, `updated_at_ms` frais.
+- **Pas de nouveau port.** Use case applicative `ReconcileLiveState` (compose `LiveStateStore` + `LiveAgentRegistry` + `Clock`) + transformation **pure** `LiveState::reconcile_orphans(is_live, now)` dans `domain/src/live_state.rs`. Provider par-root côté app-tauri (calqué sur `LiveStateProvider`/`live_state_for`).
+- **Self-only de `idea_workstate_set`** : invariant **de la surface MCP**, pas du store. `set_workstate` lie `agent_id`=identité handshake ; `UpdateLiveState`/`LiveStateStore` sont identity-agnostic. La réconciliation est un **acte système** dans le composition root qui appelle le port directement, **jamais** via `OrchestratorCommand::SetWorkState` → self-only préservé par construction. Même split que `snapshot_running_agents`/`reconcile_layouts`.
+
+Fichiers probables : `domain/src/live_state.rs`, `application/src/workstate/{mod.rs,reconcile.rs}`, `app-tauri/src/{lib.rs,state.rs,commands.rs}`. Voir [[live-state-persistence-program-closed-ls8]], [[handoff-ls5-summary-bound-and-llm-seam]].

.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/opencode-llamacpp-replaces-ollama.md

@@ -0,0 +1,35 @@
+---
+name: opencode-llamacpp-replaces-ollama
+description: memory note opencode-llamacpp-replaces-ollama
+metadata:
+  type: project
+---
+---
+title: OpenCode local provider — llama.cpp remplace Ollama (chantier livré)
+type: decision
+description: Le provider local d'OpenCode passe d'Ollama à llama.cpp (llama-server OpenAI-compatible). Profil éditable baseURL/apiKey/model. Livré sur develop (merge 2e98f1f). Clôt le diagnostic tool-calling Ollama.
+---
+
+# OpenCode local : llama.cpp remplace Ollama (2026-07-11)
+
+## Pourquoi
+Le tool-calling des modèles locaux via **Ollama** ne s'est jamais déclenché nativement en live : OpenCode fuyait les appels d'outils en texte `<function=...>` (émulation par prompt), jamais parsés. Diagnostic utilisateur : la faute est dans la relation **OpenCode↔Ollama**. Décision : abandonner Ollama comme provider OpenCode et passer à **llama.cpp** (`llama-server`, endpoint OpenAI-compatible). Voir historique : [[opencode-config-model-agnostic-tool-diagnostic]], [[opencode-ollama-native-tool-call-flag]], [[opencode-ollama-tool-calling-surface-overload]] (contexte Ollama, désormais superseded).
+
+## Contrat livré
+`OpenCodeConfig` (domaine + DTO app-tauri + type frontend) :
+`{ baseURL: String (requis, http/https), apiKey: Option<String>, model: String (requis), reasoning: Option<bool>=true, attachment: Option<bool>=false }`. Sérialisation wire camelCase (`baseURL` via serde rename), `apiKey`/`reasoning`/`attachment` `skip_serializing_if=None`.
+
+Seed profil canonique : `opencode-ollama` → **`opencode-llamacpp`** ("OpenCode + llama.cpp"), command `opencode`, adapter `OpenCode`, defaults `baseURL=http://localhost:8080/v1`, `apiKey=sk-no-key`, `model=qwen3-coder-30b`.
+
+`opencode_config_json` (crates/application/src/agent/lifecycle.rs) régénère un opencode.json MINIMAL : provider `llamacpp` (`npm=@ai-sdk/openai-compatible`, `options.baseURL/apiKey` du profil, def modèle `llamacpp/<model>` avec `tool_call:true,reasoning,attachment`), MCP `idea` inchangé, `permission bash/edit=ask`, `disabled_providers=["anthropic","openai","gemini","ollama"]`. `apiKey` omis (pas `null`) si absent. Plus aucun résidu `ollama`/préfixe `ollama/`/allow-list diagnostic.
+
+Frontend : wizard profil OpenCode = 3 champs éditables **Base URL / Model / API key(optionnel)** (`FirstRunWizard.tsx`, `profile.ts`, mocks). L'embedder Ollama (`ollamaDetected`, mémoire vectorielle) est un AUTRE usage, NON touché.
+
+## État
+- Fichiers : domain/profile.rs, application/{catalogue.rs,lifecycle.rs,tests/agent_lifecycle.rs}, infrastructure/session/opencode.rs ; frontend domain/index.ts, adapters/mock/*, features/first-run/*.
+- QA VERT : domain 244, application 81+64, infra 263/10 (les 10 = bind-port sandbox, identiques sur develop = non-régression), frontend 574, tsc propre. Claude/Codex non régressés.
+- Git : commit `4e70631`, merge `--no-ff` `2e98f1f` sur `develop`. Base branche = `eaba05d` (profil OpenCode process-backed). WIP diagnostic Ollama capsulé dans `3cdedf2` sur `feature/opencode-glm47-flash-tool-diagnostic`. PAS de push distant.
+- Tickets : #32 fermé ; #42/#43 (Ollama) retirés du store.
+
+## Reste ouvert
+E2E live llama.cpp jamais exécuté (aucun `llama-server` joignable sur :8080 au moment QA ; `llama-server` 9859 + `opencode` 1.17.18 installés). À valider côté utilisateur : lancer llama-server, relancer l'Appointe rebuild, créer un agent profil llama.cpp, vérifier un vrai `tool_use` MCP (pas de `<function=` texte). Rebuild AppImage requis pour le live (binaire qui tourne = AppImage). Build via `NO_STRIP=true` cf [[appimage-build-no-strip-relr-dyn-fix]].

.ideai/memory/rendezvous-600s-cap-too-short-heavy-tasks.md

@@ -0,0 +1,37 @@
+---
+name: rendezvous-600s-cap-too-short-heavy-tasks
+description: memory note rendezvous-600s-cap-too-short-heavy-tasks
+metadata:
+  type: project
+---
+---
+name: rendezvous-600s-cap-too-short-heavy-tasks
+description: FIX LIVRÉ (2026-06-24) du plafond rendez-vous 600s trop court (T7) — watchdog d'inactivité + extension sur signe de vie + plafond absolu, message distinct cible-active vs no-reply. Built, tests verts, AppImage 09:21 ; validation live T7 en attente.
+metadata:
+  type: project
+---
+# T7 — plafond rendez-vous trop court : FIX LIVRÉ (2026-06-24)
+
+## Défaut (rappel, observé 2026-06-23)
+Délégation dev lourde (impl + `cargo test --workspace` + clippy) → la cible bosse en **un seul long tour > 600 s sans émettre de `turn_duration`**. L'enveloppe serveur `timeout(600s, dispatch)` plate (`crates/infrastructure/src/orchestrator/mcp/server.rs`) expirait sec : (a) faux `-32001`/no-reply **retryable** alors que la cible n'est pas muette mais active ; (b) drop du `dispatch` → canal de report mort → `idea_reply` final non livrable (« no pending request »).
+
+## Fix (branche de travail courante, pas encore committé)
+Implémenté par subagent Claude (Architect+DevBackend, hors `idea_ask_agent` car le rendez-vous était le sujet), vérifié par Main (QA réelle), AppImage rebuildée.
+- **Algorithme `run_inactivity_watchdog`** dans `server.rs` : `ASK_RENDEZVOUS_TIMEOUT` (600 s, env `IDEA_ASK_RENDEZVOUS_TIMEOUT_MS`) devient une **fenêtre d'inactivité (budget de silence)**, pas un plafond absolu. Boucle `timeout(fenêtre, dispatch)` ; à chaque expiration, sonde l'activité de la cible :
+  - progrès & sous plafond → réarme (extension) ;
+  - progrès & plafond atteint → **`rendezvous_ceiling_active_error`** (nouveau code JSON-RPC `error_codes::RENDEZVOUS_CEILING_ACTIVE = -32_002`, `data.code="RENDEZVOUS_CEILING_ACTIVE"`, **`retryable:false`**, message « still actively working… do not retry blindly, check the target's in-progress work/branch ») ;
+  - pas de progrès (vrai silence, ou **pas de probe = fallback plat**) → `rendezvous_no_reply_error` inchangé (`retryable:true`).
+- **Signe de vie = octets cumulés des `.jsonl`** du run-dir cible (couvre le long tour unique sans `turn_duration`). Nouvelle `inspector::claude_paths::transcript_activity_token(fs, home, cwd) -> Option<u64>`.
+- **Plafond absolu** `ASK_RENDEZVOUS_CEILING` (défaut **4 h**, env `IDEA_ASK_RENDEZVOUS_CEILING_MS`).
+- **Wiring** : sonde optionnelle `AskActivityProbe` injectée dans `McpServer` (modèle `events`/`ready_sink`, additif → zéro régression), branchée par la composition root `crates/app-tauri/src/state.rs` (qui résout nom→AgentId→run-dir via nouveau `service.resolve_agent_id_by_name`). Infra reste libre d'`AgentId`.
+- Fichiers : `server.rs`, `jsonrpc.rs`, `mcp/mod.rs`, `lib.rs`, `inspector/claude_paths.rs`+`mod.rs`, `application/.../service.rs`, `app-tauri/state.rs`.
+
+## Validation (preuve réelle, Main)
+`cargo test -p infrastructure --lib` = **251 passed/0** (dont 6 nouveaux tests : silence→no-reply, fallback sans probe→no-reply, active→extension puis resolved, active→ceiling, codes/retryable distincts). `mcp_server` 22/0, `inspector_claude` 4/0, `cargo test -p application` tout vert. `clippy -p infrastructure -p application --all-targets` = **0 warning nouveau** (résiduels pré-existants : input/mod.rs, lifecycle.rs, fileguard.rs, server.rs:132 ready_sink). **AppImage rebuildée 2026-06-24 09:21**, installée sur `/home/anthony/Documents/IdeA_0.3.0_amd64.AppImage`, backup `…​.old-pre-t7-fix` (08:41).
+
+## Reste à faire
+1. **Validation live T7** après relance IdeA : déléguer une tâche lourde >600 s ; attendu = pas d'expiration tant que la cible écrit son transcript, et soit résolution normale, soit (si >4 h) message ceiling-active non-retryable distinct ; idea_reply tardif non perdu tant qu'on n'a pas atteint le plafond.
+2. **Commit par Git** (non fait — laissé à Git, cf. [[git-owns-commit-merge-decisions]]) : décider de le faire avant ou après la validation live T7.
+3. Reprise complète des tests **depuis T1** (skill mcp-rendezvous-functional-test). État pré-relance : T1→T6 verts cette passe, dont fix T5 validé live (cf. [[checkpoint-mcp-tests-t1-t5-and-t5-livestate-defect]]).
+
+Lié à [[rendezvous-no-reply-backstop-design]], [[backstop-fires-on-intra-task-turn-rootcause]], [[mcp-functional-test-plan-2026-06-24]].

.ideai/memory/rendezvous-no-reply-backstop-design.md

@@ -0,0 +1,14 @@
+---
+name: rendezvous-no-reply-backstop-design
+description: Décision d'architecture sur la fin-de-tour et le backstop no-reply du rendez-vous idea_ask_agent ⇄ idea_reply, après échec live du fix Finding A (77e62e5).
+metadata:
+  type: reference
+---
+Le watcher prompt-ready PTY (`infrastructure/src/input/mod.rs` `arm_prompt_watcher`) ne peut PAS servir de signal de fin-de-tour : il est one-shot ré-armé seulement au `bind_handle`, et matche un bandeau TUI **permanent** (`? for shortcuts`) — donc inopérant par tour. Preuve live : aucun `prompt_ready` de toute une session alors que l'agent a travaillé ⇒ c'est le handshake MCP `initialize` (→ `release_agent_cold_start`) qui libère le cold-start, pas le PTY.
+
+**Contrat figé** : `idea_ask_agent` est garanti libéré en temps borné par l'un de :
+1. `idea_reply` (chemin propre, renforcé par le préambule comportemental injecté à chaque délégation) ;
+2. backstop no-reply sur **stagnation** — transition `Alive→Stalled` (lot-2 `arm_liveness`/`sweep_stalled`) du `Busy{ticket}` ⇒ résolution synthétique « cible silencieuse sans idea_reply » + libération du demandeur ;
+3. timeout absolu **fini** (dernier recours) — `ASK_RENDEZVOUS_TIMEOUT` ne doit JAMAIS être 24h ; défaut reco 600 s, env-overridable, garde `Some(0)=no-override`. La borne applicative per-tour (`resolve_turn_timeout`) doit aussi être finie.
+
+Le scraping d'octets ANSI bruts est interdit comme autorité de fin-de-tour (fragile, profil-spécifique). Cold-start = signal MCP `initialize`. Aucun port domaine ni contrat de cartographie n'est touché : tout est infrastructure/application (réutilise lot-2 + sink MCP). Diagnosticabilité : les logs d'armement/bind doivent être en `diag!` (pas `eprintln!`→/dev/null) pour observer armement vs match.

.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/skills-integration-canonical-foundation.md

@@ -0,0 +1,11 @@
+---
+name: skills-integration-canonical-foundation
+description: Topologie d'intégration du chantier skills agent et décision d'abandon de feature/agent-skills.
+metadata:
+  type: project
+---
+Le chantier « skills agent » : la fondation canonique du domaine skills est **déjà dans `develop`** (introduite par `2332b7f` : port `SkillStore`, `SkillRef` sur `ManifestEntry`, `resolve_skills` dans `LaunchAgent`, CRUD + assign/unassign, **frontend complet** `features/skills/*`).
+
+- `feature/agent-skills` (A, @ef101db) = réimplémentation **obsolète et incompatible** (serde `tag="type"`, `with_updated_content`, pas de `SkillRef`/frontend). **À abandonner** — ne jamais merger, elle régresse develop.
+- `feature/agent-skill-awareness` (B, @5be8987) = **surensemble propre** de develop (sa base `8452333` est ancêtre de develop ; diff skill = +539/−3). Apporte : `Skill.description`/`effective_description`, manifeste, outil MCP `idea_skill_read` (variante domaine `OrchestratorCommand::ReadSkill`), brief « capacités IdeA » inconditionnel dans `compose_convention_file`.
+- Intégration = cherry-pick `ab34363`(+`1a10d67` squash) puis `566bff4` sur develop ; **exclure** `e93a2c1` (cold-start, superseded par `8bb832c`) et le bruit `.ideai/*` (garder seulement `.ideai/memory/feature-agent-skill-awareness-design.md`). Dropper `e93a2c1` évite tout conflit sur `input/mod.rs`. Points chauds : `lifecycle.rs`, `state.rs`.

.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/ticket13-f0-frontend-transport-inventory.md

@@ -0,0 +1,23 @@
+---
+name: ticket13-f0-frontend-transport-inventory
+description: Résultat de l'inventaire B0/F0 frontend du chantier client/serveur #13 — la frontière gateways transport-neutres existe déjà, F1 = ajout d'adapters HTTP+WS.
+metadata:
+  type: reference
+---
+Inventaire B0/F0 (ticket #13 server/client mode), côté frontend TS/React. Doc : `docs/ticket13-f0-frontend-transport-inventory.md`.
+
+**Constat clé** : la frontière « gateways TS transport-neutres » du plan est DÉJÀ réalisée et testée.
+- `src/ports/index.ts` = 21 gateways sans Tauri ; toute la couche `features/`+`app/` en dépend via DI (`useGateways()`).
+- `src/adapters/*` = seul lieu important `@tauri-apps/api`.
+- Garde L1 `src/app/no-direct-invoke.test.ts` casse la CI si un fichier hors `adapters` importe Tauri / appelle `invoke(`.
+- `src/app/di.tsx` `resolveGateways()` bifurque déjà Tauri vs mock → F1 = ajouter `createHttpWsGateways()` (3ᵉ impl).
+
+**Donc F1 = écrire un 2ᵉ jeu d'adapters derrière des ports inchangés, aucun composant métier à réécrire.**
+
+**Flux Channel (→ WebSocket)** : (1) `terminal.ts` PTY, (2) `agent.ts` PTY agent (réutilise `makeTerminalHandle`), (3) `ticket.ts` `sendTicketChat` `Channel<ReplyChunk>`. Tous modélisés côté port par callback `onData`/`onChunk`. Le contrat PTY WS du carnet mappe 1-pour-1 sur `TerminalHandle` (write/resize/detach/close, detach≠close, scrollback au reattach) → port inchangé pour F3. `TerminalView.tsx` ne connaît que le port.
+
+**Event portable** : `system.onDomainEvent("domain://event")` (bus domaine) → WS serveur→client.
+
+**Desktop-only à cadrer** : `system.pickFolder` (dossier = machine serveur ≠ client web → file-picker serveur), `window.ts` (WebviewWindow OS) et `focusedProject.ts` (multi-fenêtres OS) probablement hors V1 web. `uiPreferences` (localStorage) marche tel quel.
+
+Convention DTO à préserver côté adapter HTTP : commandes snake_case, payloads camelCase souvent enveloppés `{ request: {...} }`.

.ideai/memory/ticket13-f1-http-ws-adapter-delivered.md

@@ -0,0 +1,17 @@
+---
+name: ticket13-f1-http-ws-adapter-delivered
+description: Le 3e jeu d'adapters frontend (HTTP request/response + squelette WebSocket) du chantier client/serveur #13 est livré et vert, derrière les ports inchangés.
+metadata:
+  type: reference
+---
+Ticket #13 lot F1 livré sur feature/ticket13-server-client-mode. Nouveau dossier `frontend/src/adapters/http/` = 3e implémentation des gateways, à côté de Tauri (desktop) et mock.
+
+**Fichiers** : `httpInvoker.ts` (POST /api/invoke {command,args}, ErrorDto→GatewayError, fetch injectable), `frames.ts` (contrat frames WS B0 + base64), `wsLiveClient.ts` (squelette WS multiplexé : corrélation id↔replyTo, routage terminal.output par session, dispatch event.domain), `requestResponseGateways.ts` (13 gateways R/R, commandes/enveloppes IDENTIQUES aux adapters Tauri), `streamGateways.ts` (HttpSystem/Agent/Ticket/Terminal + makeWsTerminalHandle detach≠close), `unsupported.ts` (Web{Window,FocusedProject,Remote}Gateway, code UNSUPPORTED_ON_WEB), `index.ts` (createHttpWsGateways(config?), endpoints via window.location). Tests : httpInvoker.test.ts, wsLiveClient.test.ts.
+
+**Seam DI** : `app/di.tsx` → `resolveTransport()` 3-way (mock > http > tauri), web sélectionné par `VITE_TRANSPORT="http"`. Tauri reste défaut (desktop inchangé).
+
+**Décision de contrat clé (à confirmer DevBackend)** : transport RPC générique `POST /api/invoke {command,args}` choisi PLUTÔT que l'arbre REST du brouillon B0 — préserve 1:1 tous les DTO Tauri, zéro divergence, bascule REST future ne touche que httpInvoker.ts. Autres points à trancher : placement token WS (pas en URL ; navigateur ne peut pas fixer d'en-tête upgrade), forme réponse terminal.open/agent.launch (ack terminal.attached avec session.sessionId), projectId absent du port openTerminal.
+
+**Reporté F3/B5/B6** (TODO(F3/B5)) : round-trip xterm réel, reconnexion/backpressure, replay seq/gap, sink chat par-session pour sendTicketChat, agents structurés. Pas de serveur avant B3/B4.
+
+État : build vert (tsc+vite), garde no-direct-invoke verte, 77 fichiers/724 tests verts. Voir [[ticket13-f0-frontend-transport-inventory]].

.ideai/memory/ticket13-f2-web-readonly-client-delivered.md

@@ -0,0 +1,19 @@
+---
+name: ticket13-f2-web-readonly-client-delivered
+description: Le client web read-only (pairing cookie, liste projets, ouverture read-only + snapshot work-state) du chantier client/serveur #13 est livré et vert.
+metadata:
+  type: reference
+---
+Ticket #13 lot F2 livré sur feature/ticket13-server-client-mode. Clôture frontend du premier incrément livrable (B0→B4/F2).
+
+**Nouveau** : `adapters/http/webSession.ts` (WebSession : flag localStorage « paired » — PAS le cookie HttpOnly ; `pair(code)`→POST /api/pair ; `notifyUnauthorized()` clear+notify ; singleton `getWebSession()`), `features/web/` (PairingScreen, WebWorkspace read-only, WebApp gate). Tests : webSession.test.ts, WebApp.test.tsx.
+
+**Modifié** : httpInvoker (credentials same-origin + callback onUnauthorized sur 401), http/index.ts (câble onUnauthorized→webSession), app/main.tsx (monte <WebApp/> si resolveTransport()==="http", desktop inchangé).
+
+**Flux** : non-paired→PairingScreen ; pair OK (cookie HttpOnly posé serveur)→WebWorkspace ; 401 d'un /api/invoke→retour pairing ; « se déconnecter »=clear flag local (révocation serveur=B8). Cookie jamais lisible en JS (HttpOnly) : on se fie au 200 + flag de routage.
+
+**Read-only** : WebWorkspace n'appelle QUE list_projects, open_project, get_project_work_state (via gateways DI). N'appelle PAS onDomainEvent/health/firstRunState → aucune commande hors-allowlist, pas de WS (live update = F3/B5, snapshot ponctuel pour l'instant).
+
+**À confirmer B4** : get_project_work_state dans l'allowlist ; open_project sans effet de bord dangereux en read-only ; 401 (pas 403) sur cookie manquant ; code HTTP mauvais code /api/pair (401/403 → « Code d'appairage invalide »).
+
+Build vert, garde no-direct-invoke verte, 79 fichiers/736 tests verts, desktop inchangé. Suite de [[ticket13-f1-http-ws-adapter-delivered]] ; inventaire [[ticket13-f0-frontend-transport-inventory]].

.ideai/memory/ticket13-f3-xterm-websocket-delivered.md

@@ -0,0 +1,19 @@
+---
+name: ticket13-f3-xterm-websocket-delivered
+description: L'adapter WS terminal (round-trip xterm, reconnexion+replay, états connexion) du chantier client/serveur #13 est finalisé et vert côté frontend.
+metadata:
+  type: reference
+---
+Ticket #13 lot F3 livré sur feature/ticket13-pty-websocket. Finalise l'adapter WS terminal depuis le squelette F1. Travail 100% dans frontend/src/adapters/http/ ; port TerminalGateway/TerminalHandle et TerminalView INCHANGÉS.
+
+**wsLiveClient.ts** : machine d'état connexion (connecting/connected/reconnecting/closed, getConnectionState()+onConnectionStateChange), reconnexion auto (backoff, setTimeout injectable) → re-attach_terminal avec lastSeq + repaint scrollback borné + notices « déconnecté »/« reconnecté » écrites dans xterm via le sink. Suivi des sessions terminales (map `terminals`) pour le replay. Routage terminal.status exited → notice + onStatus + untrack. openTerminal/attachTerminal/detachTerminal/closeTerminalSession haut-niveau. API bas-niveau F1 (setOutputSink/send/domain events) conservée pour agent/system gateways.
+**streamGateways.ts** : HttpTerminalGateway délègue aux nouvelles méthodes ; makeWsTerminalHandle.detach→detachTerminal (untrack, PTY vivant), close→closeTerminalSession (tue).
+**frames.ts** : AttachedPayload.status? + StatusPayload.
+
+**Contrat B5 (server.rs) confirmé** : frames terminal.open{cwd,rows,cols} (pas de projectId)/attach{sessionId,rows,cols,lastSeq}/input{sessionId,bytesBase64}/resize/detach/close/ping ↔ terminal.attached{session,scrollback:[{seq,bytesBase64}],nextSeq,status,gap,assignedConversationId}/output{sessionId,seq,bytesBase64}/status{sessionId,status,exitCode}/error/pong. Ack unifié terminal.attached. Scrollback = 1 entrée seq:0 (tous octets) ou vide.
+
+**Écarts B5 à arbitrer** : (1) pas de replay delta — le serveur rejoue TOUT le scrollback, lastSeq ne sert qu'au flag gap ⇒ duplication possible à la reconnexion (conforme « V1 scrollback borné »). (2) multi-onglets « dernier gagne » SILENCIEUX — l'attachement évincé ne reçoit aucune frame (pas de crash, mais pas d'indication). (3) indication d'état = notices dans xterm (port inchangé).
+
+**Tests** : terminalGateway.test.ts (round-trip), wsLiveClientReconnect.test.ts (états/reconnexion/exited). Build vert, garde no-direct-invoke verte, 81 fichiers/743 tests verts, desktop inchangé.
+
+**Bloqueur run live** (dette carnet, hors F3) : `idea --serve` ne sert pas les assets web same-origin ⇒ app web pas lançable en navigateur tant que le lot « servir dist/ » n'est pas fait. Suite de [[ticket13-f1-http-ws-adapter-delivered]], [[ticket13-f2-web-readonly-client-delivered]].

.ideai/memory/ticket13-f4-web-agent-surface-delivered.md

@@ -0,0 +1,19 @@
+---
+name: ticket13-f4-web-agent-surface-delivered
+description: L'agent CLI web (agent.launch → terminal.attached, réattache sans relance, cellule agent réutilisant TerminalView) du chantier client/serveur #13 est livré et vert côté frontend.
+metadata:
+  type: reference
+---
+Ticket #13 lot F4 livré sur feature/ticket13-pty-websocket. Rend la surface agent fonctionnelle en mode web via les gateways DI ; CLI serveur, web = affichage.
+
+**Adapter** : wsLiveClient.launchAgent(params) réutilise attachInternal de F3 → frame agent.launch, ack unifié terminal.attached, session trackée dans la map `terminals` (reconnexion/replay/exited comme un terminal), renvoie {sessionId, scrollback, assignedConversationId, status}. HttpAgentGateway.launchAgent → ws.launchAgent (pose assignedConversationId sur le handle) ; HttpAgentGateway.reattach → ws.attachTerminal (frame terminal.attach, PAS de relance). Chemin bas-niveau F1 dupliqué supprimé.
+
+**UI (câblage, pas de nouveau composant terminal)** : features/web/WebAgentCell.tsx réutilise TerminalView (agentMode) avec agent gateway DI comme open=launchAgent/reattach=reattach, persiste sessionId. WebWorkspace : affordance « Ouvrir » par agent du snapshot work-state → monte WebAgentCell.
+
+**Contrat B6 (server.rs) confirmé, aucun écart** : agent.launch payload plat camelCase {projectId,agentId,nodeId,rows,cols,conversationId} → ack terminal.attached{assignedConversationId}. Agent structuré → erreur UNSUPPORTED (canal PTY-only) surfacée par la bannière TerminalView. Réattache = terminal.attach (no respawn). Singleton guard AGENT_ALREADY_RUNNING déjà géré par TerminalView.
+
+**Points UI à signaler** : (1) l'affordance liste les agents du snapshot work-state ; lister tous les agents exigerait list_agents sur l'allowlist B4. (2) write-portal (injection délégation) NON câblé en web V1 (affichage + frappe seulement). (3) WebAgentCell ne gère pas de nœud layout.
+
+**Tests** : adapters/http/agentGateway.test.ts (launch/assignedConversationId/reattach/input/output/resize/UNSUPPORTED/NOT_FOUND), WebApp.test.tsx (+ouverture cellule). Build vert, garde no-direct-invoke verte, 82 fichiers/749 tests verts, desktop inchangé.
+
+**Bloqueur run live** (dette carnet, hors F4) : `idea --serve` ne sert pas les assets web same-origin ⇒ round-trip navigateur pas validable tant que le lot « servir dist/ » n'est pas fait. Suite de [[ticket13-f3-xterm-websocket-delivered]], [[ticket13-f1-http-ws-adapter-delivered]], [[ticket13-f2-web-readonly-client-delivered]].

.ideai/memory/ticket13-f5-web-live-surfaces-delivered.md

@@ -0,0 +1,17 @@
+---
+name: ticket13-f5-web-live-surfaces-delivered
+description: 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.
+metadata:
+  type: reference
+---
+Ticket #13 lot F5 livré sur feature/ticket13-pty-websocket. Rend les surfaces live fonctionnelles en mode web.
+
+**Réutilisation clé** : le hook desktop transport-neutre `features/workstate/useProjectWorkState` (refresh du read-model sur event.domain) est réutilisé TEL QUEL — c'est lui qui donne la parité live. PAS de réutilisation de ProjectWorkStatePanel (dépend de useLayout + attach/stop-vers-cellule, spécifiques au grid desktop, hors read-only). WebWorkspace rend une vue lean : agents live/idle/busy, background tasks (Cancel/Retry via workState gateway), inbox par agent, + cellule agent F4.
+
+**Adapter** : wsLiveClient.needsReconnect() = terminals.size>0 OU domainEventHandler!=null → la reconnexion marche aussi pour un abonnement live sans terminal (le handler domaine persiste à travers la reconnexion). Nouveau webLive.ts = singleton getWebLiveClient()/setWebLiveClient() (createHttpWsGateways enregistre le ws) exposant l'état de connexion au feature web SANS le mettre dans le port SystemGateway. Nouveau hook features/web/useLiveReconnect.ts : re-refresh du read-model sur transition reconnecting→connected (events manqués pendant coupure ; récupération = re-fetch complet du snapshot, pas de replay serveur).
+
+**À confirmer B7** : (1) cancel_background_task/retry_background_task sur l'allowlist web write. (2) inbox surfacée via le read-model workstate, PAS via un flux notifications distinct (si B7 en a un, non câblé). (3) re-synchro = re-fetch complet (workstate = snapshot complet), pas de delta par event.
+
+**Tests** : WebWorkspaceLive.test.tsx (event.domain→refresh, background render+cancel, reconnect re-sync), wsLiveClientReconnect (reconnexion pour abonnement domaine). Build vert, garde no-direct-invoke verte, 83 fichiers/753 tests verts, desktop inchangé.
+
+**Bloqueur run live** (dette carnet, hors F5) : `idea --serve` ne sert pas les assets web same-origin. Suite de [[ticket13-f4-web-agent-surface-delivered]], [[ticket13-f3-xterm-websocket-delivered]], [[ticket13-f2-web-readonly-client-delivered]].

.ideai/memory/ticket14-local-lan-openai-adapter-scoping.md

@@ -0,0 +1,64 @@
+---
+name: ticket14-local-lan-openai-adapter-scoping
+description: memory note ticket14-local-lan-openai-adapter-scoping
+metadata:
+  type: project
+---
+# Ticket #14 — cadrage figé : adapter IA local/LAN OpenAI-compatible canonique
+
+Périmètre figé (review agent-user faite) : canal = **adapter HTTP natif** parlant une API compatible OpenAI/Ollama ; usage **transparent** vs Claude/Codex (mêmes cellules, conversation headless canonique, historique, reprise, délégation, vivacité) ; **PUREMENT ADDITIF** (zéro régression Claude Code / Codex CLI) ; **parité tool-calling/MCP** dès ce ticket avec **dégradation propre** si le modèle n'expose pas les outils.
+
+## 0. Asymétrie structurelle (commande TOUT le design)
+| | Claude/Codex (existant) | Modèle local HTTP (#14) |
+|---|---|---|
+| Nature | binaire CLI spawné | serveur HTTP appelé |
+| Boucle agentique | conduite par la CLI | conduite par **IdeA** |
+| Rôle MCP d'IdeA | serveur ; CLI = client | pas de client ⇒ IdeA = orchestrateur d'outils |
+| Contexte .md | la CLI lit son convention file | injecté en **system message** par l'adapter |
+| Conversation | id moteur (session_id/thread_id) | API **stateless** ⇒ transcript possédé par IdeA |
+Conséquence : le nouvel adapter **n'utilise PAS** `session/process.rs` (run_turn/spawn/drain). Il ne partage avec claude.rs/codex.rs que les **types de port** (`AgentSession`, `ReplyEvent`). Cette absence de code partagé mutable EST la garantie d'isolation.
+
+## 1. Cartographie hexagonale
+**Domaine (crates/domain)**
+- Variante `StructuredAdapter::OpenAiCompatible` (profile.rs:244). `provider_key()` ⇒ `"openai-compatible"` (contrat persistance providers.json). Sérialise camelCase `"openAiCompatible"`.
+- Nouveau VO validé (parse-don't-validate) `HttpChatConfig { endpoint:String (http/https non vide), model:String (non vide), api_key_env:Option<String> (nom de var env valide, JAMAIS la clé), request_timeout_ms:Option<u32>, connect_timeout_ms:Option<u32>, max_tool_iterations:Option<u16> (garde-fou boucle, défaut ~16) }`. Le domaine ne résout jamais la clé (pas d'I/O env), il porte le **nom** de variable.
+- Rattachement `AgentProfile.chat_http: Option<HttpChatConfig>` avec `#[serde(default, skip_serializing_if="Option::is_none")]` (miroir exact de `mcp`/`liveness`/`rate_limit_pattern`, profile.rs:570-604) ⇒ **zéro régression de sérialisation** (profils Claude/Codex bit-identiques). Test round-trip obligatoire (miroir profile_without_mcp_round_trips_identically).
+
+**Nouveau port tool-calling (le seam clé — le pont MCP .mcp.json/config.toml + bridge `idea mcp-server` NE s'applique pas, pas de client CLI)**
+```rust
+pub struct ToolSpec { name:String, description:String, input_schema:serde_json::Value }
+#[async_trait] pub trait ToolInvoker: Send+Sync {
+    fn tools(&self) -> Vec<ToolSpec>;
+    async fn call(&self, name:&str, args_json:&str) -> Result<String, ToolInvocationError>;
+}
+```
+Implémenté en **app-tauri** en déléguant à la **même** `OrchestratorService::dispatch` (orchestrator/service.rs:1082) que le endpoint MCP ⇒ parité délégation/rendez-vous (idea_ask_agent/idea_reply), gating permissions/sandbox conservé. Injecté dans la factory via `with_tool_invoker(Arc<dyn ToolInvoker>)` (jumeau de `with_sandbox_enforcer`). `None` ⇒ tool-calling désactivé proprement (chat nu).
+
+**Infra** : nouveau fichier `crates/infrastructure/src/session/openai_compat.rs` (jumeau structurel de codex.rs SANS process). Client HTTP **reqwest + rustls-tls** (jamais native-tls — spike AppImage §13-2, confiné au crate infra). Parsing isolé pur `parse_chat_delta`/`parse_completion` (miroir de parse_event) — seul endroit qui connaît le schéma OpenAI (choices[].message, tool_calls[], SSE data:).
+
+**Routing — seul contact avec l'existant** : `StructuredSessionFactory::start` (factory.rs:111) = **UN bras de match ajouté** ; bras Claude/Codex INTOUCHÉS ; `supports()` reste `profile.is_selectable()` (=structured_adapter.is_some(), profile.rs:857) ⇒ sélectionnable sans changer le prédicat.
+
+## 2. Contrat de session headless
+`send(prompt)` : 1) transcript.push(user) ; 2) émettre Heartbeat ; 3) POST {endpoint}/chat/completions {model, messages:transcript, tools?:invoker.tools(), stream:true} ; 4) si tool_calls ⇒ pour chaque: ToolActivity{label=name} + result=invoker.call(name,args) + push(assistant tool_call)+push(tool result), reboucler (borné max_tool_iterations) ; 5) sinon streamer chunks ⇒ TextDelta (+tap→Announcement, cf claude.rs:337) ; 6) réponse complète ⇒ push(assistant) + **Final{content}** ; 7) persister transcript run dir. Contrat de flux universel respecté (un seul Final terminal) ⇒ send_blocking/drain_with_readiness marchent tels quels.
+
+**Erreurs (jamais de corps HTTP brut propagé)** : endpoint injoignable 1er contact/probe ⇒ `AgentSessionError::Start` (UI erreur, IdeA non bloqué) ; réseau/coupure en tour ⇒ `Io` ; JSON illisible/schéma ⇒ `Decode` (diagnostic court) ; timeout ⇒ `Timeout` via send_blocking, session non tuée ; modèle absent (404/400) ⇒ `Start` dédié.
+
+**Reprise sans mélange d'ids (invariant du ticket)** : /chat/completions **stateless** ⇒ AUCUN id provider ⇒ `conversation_id()` retourne **None** (rien à mélanger). État = transcript provider-shaped (roles+tool_calls) **possédé par IdeA**, persisté dans le **run dir stable** `.ideai/run/<agent-id>/chat-transcript.json` (clé = agent, jamais id provider). Reprise = ré-instanciation factory ⇒ rechargement transcript ; `seed_conversation_id` (factory.rs:63) **ignoré** par cet adapter (documenter). DISTINCT du conversation-log LS6 (log.jsonl, dérivé ReplyEvent, surface humaine, inchangé) — deux artefacts, aucun mélange.
+
+**Contexte** : `start` reçoit `ctx:&PreparedContext` ; `ctx.content` (ports.rs:120) = Markdown rendu ⇒ injecté comme premier message **system** (le serveur HTTP ne lit pas de convention file).
+
+## 3. Seam tool-calling / dégradation
+Parité : ToolInvoker câblé ⇒ modèle local voit idea_* via la même OrchestratorService (délégation/rendez-vous/contexte/mémoire/tickets identiques, gating conservé). Dégradation 3 niveaux : (1) ToolInvoker None ⇒ chat nu ; (2) profil opte sans outils ⇒ idem ; (3) endpoint rejette param `tools` ⇒ détecter, retirer tools, rejouer chat nu, 1 diagnostic — l'agent converse toujours, sans déléguer. Garde-fou max_tool_iterations (modèles locaux moins fiables) ⇒ au plafond, Final + note.
+
+## 4. Lots B/F
+Backend : **B1** domaine (variante+provider_key, VO HttpChatConfig, champ chat_http, port ToolInvoker/ToolSpec/ToolInvocationError ; tests sérialisation zéro-régression, round-trip, invariants ; zéro I/O). **B2** adapter infra openai_compat (reqwest/rustls, parse_* purs, mapping ReplyEvent+erreurs, résolution clé env ; tests fixtures OpenAI/Ollama, erreurs via wiremock, pas de fuite payload). **B3** boucle outils bornée + persistance/rechargement transcript run-dir (reprise) + dégradation tools non supporté (tests ToolInvoker fake, reprise=rechargement, plafond). **B4** routing (bras match) + composition root (with_tool_invoker, impl ToolInvoker→OrchestratorService) + profil de référence "Ollama / OpenAI-compatible local model" éditable (tests factory route, supports true, probe indispo→Start).
+Frontend : **F1** types TS HttpChatConfig + champ chatHttp? + adapter "openAiCompatible". **F2** wizard/settings : sélectionnable comme Claude/Codex, form endpoint/model/apiKeyEnv/timeouts, validation miroir backend (first-run/profile.ts isValidEnvVar, URL, non-vide), apiKeyEnv = nom de var jamais clé. **F3** cellule = chemin chat structuré existant (dérivé de is_selectable, "gratuit" si DTO respecté) + erreur "endpoint indisponible" propre sans bloquer UI (tests RTL gateways mock).
+Frontière B↔F : **DTO AgentProfile** (déjà le pont IPC) porte structuredAdapter:"openAiCompatible" + chatHttp{endpoint,model,apiKeyEnv?,requestTimeoutMs?,connectTimeoutMs?,maxToolIterations?}. Sélectionnabilité + rendu chat dérivés du DTO existant, pas de nouveau canal ni commande Tauri au cœur (le seed du profil de référence peut passer par le CRUD profils existant — à confirmer B4/F3).
+
+## 5. Vigilance régression / invariants
+1. Zéro régression sérialisation (skip_serializing_if=Option::is_none ; round-trip Claude/Codex bit-identique — BLOQUANT). 2. Isolation code : nouvel adapter = fichier neuf ; INTERDIT de toucher claude.rs/codex.rs/process.rs ; seul diff existant = 1 bras match factory.rs + champs optionnels domaine. 3. Contrat flux : exactement un Final terminal ; Heartbeat/ToolActivity/TextDelta/RateLimited non terminaux (conformance.rs doit couvrir le nouvel adapter). 4. Frontière domaine : reqwest UNIQUEMENT infra ; aucun type HTTP en domaine/application ; ToolInvoker port pur. 5. Nouvelle dépendance AppImage : reqwest rustls-tls (pas OpenSSL, spike §13-2). 6. Non-mélange ids : conversation_id()=None ; transcript clé-agent ; distinct de LS6. 7. Sandbox : pas de process spawné ⇒ SandboxEnforcer OS = no-op pour le tour (pas une régression) mais les outils via ToolInvoker gardent le gating orchestrateur.
+
+## 6. Décisions produit remontées à Main (NON tranchées par Architect)
+1. Surface d'outils v1 : parité totale immédiate vs sous-ensemble curaté (fiabilité tool-calling des modèles locaux). Reco : parité + garde-fou max_tool_iterations.
+2. Streaming SSE dès v1 (reco, parité observabilité live) vs non-streaming (repli si endpoint ne stream pas).
+3. Nom canonique variante : `OpenAiCompatible` (reco, décrit le protocole ; provider_key figé) vs `LocalChat` (formulation ticket).

.ideai/memory/ticket16-menus-floating-delivered-devfrontend.md

@@ -0,0 +1,29 @@
+---
+name: ticket16-menus-floating-delivered-devfrontend
+description: memory note ticket16-menus-floating-delivered-devfrontend
+metadata:
+  type: project
+---
+# Lot A / #16 — MenuBar + FloatingWindow livré (DevFrontend)
+
+Branche `feature/ui-menus-floating` (base develop 0218e32), non commité, avant merge Git. `vitest` **vert** : 54 fichiers / 527 tests. `tsc --noEmit` exit 0.
+
+## UX pass validée utilisateur (barre unique + sélecteur projet) — APPLIQUÉE
+- **Barre unique** : plus de MenuBar séparée dans App.tsx. Une seule MenuBar dans `ProjectsView` regroupant `[ Projet: <actif> ▾ ]  File ▾  View ▾  Settings ▾`.
+- **Sélecteur de projet permanent** : premier menu de la barre, label = projet actif, items = tous les projets connus (`vm.projects`) → `selectProject(id)` (active l'onglet si ouvert, sinon `openProject`). Accessible même sous projet actif, sans ouvrir File→Projects….
+- **Settings → AI Profiles** déplacé dans la barre unique : toggle `showSettings` LOCAL à ProjectsView ; le main area swap vers `<ProfilesSettings/>` pendant que la barre reste visible (permet de refermer). App.tsx ne gère plus showSettings ni ProfilesSettings (juste firstRun ? wizard : ProjectsView).
+
+## Fichiers (état final)
+- **Créés (lot A initial)** : `shared/ui/FloatingWindow.tsx`, `shared/ui/MenuBar.tsx`, `shared/ui/FloatingWindow.test.tsx`.
+- **Modifiés** : `shared/index.ts`, `shared/ui/zIndex.ts` (réutilisé), `app/App.tsx` (barre + showSettings + ProfilesSettings retirés), `features/projects/ProjectsView.tsx` (barre unique : projectMenu+File+View+Settings, showSettings local, ProfilesSettings dans main), `features/projects/projects.test.tsx` (+2 tests : sélecteur projet, toggle AI Profiles), `features/projects/ProjectsView.ls7.test.tsx`.
+
+## Invariants conservés
+- FloatingWindow (focus-trap+Échap+backdrop, z=floatingWindow 50), MenuBar dropdowns z=menuDropdown 40, toasts z=toast 70, zIndex canonique réutilisé.
+- TOUS les panneaux atteignables via **View** (context, work, tickets, agents, templates, skills, perms, memory, git) + File→Projects…. Critère d'acceptation respecté.
+- Non touché : `shouldShowWritePortalVeil`, exclusion write-portal↔F3, overlays in-cell, TicketPicker (#18).
+
+## Notes
+- ProfilesSettings rendu DANS le main de ProjectsView (barre + onglets projet restent visibles au-dessus) au lieu du swap plein-écran App précédent — meilleure continuité, barre unique toujours accessible.
+- Pas de run live Tauri (couverture RTL mock-driven). DoD vitest satisfaite.
+
+QA/utilisateur revalident avant merge Git.

.ideai/memory/ticket17-focus-trap-fix-merged-develop.md

@@ -0,0 +1,9 @@
+---
+name: ticket17-focus-trap-fix-merged-develop
+description: Correctif de la perte de focus dans l'édition de ticket (#17) livré sur develop via feature branch dédiée.
+metadata:
+  type: reference
+---
+Bug #17 : saisie une lettre à la fois dans le formulaire d'édition de ticket, cause = focus-trap `FloatingWindow` avec `useEffect` dépendant de `[onClose]` (closure recréée à chaque render). Fix DevFrontend : `onCloseRef` + effet focus-trap mount-only (`[]`).
+
+Topologie Git : branche `feature/ticket17-focus-trap-fix` depuis `develop`, commit `4cccd40` (2 fichiers frontend seulement), merge `--no-ff` → `develop` = `2f8467e`, branche supprimée. Vert : tsc clean, 531/531 + test de régression. Voir [[ticket16-menus-floating-delivered-devfrontend]], [[ui-rework-sprint-scoping-contracts]].

.ideai/memory/ticket18-picker-delivered-devfrontend.md

@@ -0,0 +1,28 @@
+---
+name: ticket18-picker-delivered-devfrontend
+description: memory note ticket18-picker-delivered-devfrontend
+metadata:
+  type: project
+---
+# Lot B / #18 — TicketPicker livré (DevFrontend)
+
+Branche `feature/ticket-picker-popup` (base develop d97abb1). `vitest` **vert** : 53 fichiers / 515 tests, dont 8 nouveaux (`TicketPicker.test.tsx`) + 29 `tickets.test.tsx` inchangés (valide la non-régression du listing après extraction). `tsc --noEmit` clean.
+
+## Fichiers
+- **Créés** : `shared/ui/zIndex.ts`, `features/tickets/TicketFacetsBar.tsx`, `features/tickets/useTicketSearch.ts`, `features/tickets/TicketPicker.tsx`, `features/tickets/TicketPicker.test.tsx`.
+- **Modifiés** : `shared/index.ts` (export zIndex), `features/tickets/index.ts` (barrel), `features/tickets/TicketsPanel.tsx` (consomme `TicketFacetsBar`).
+
+## Écarts de contrat à trancher (signalés à Main)
+1. **Emplacement TicketPicker** : placé sous `features/tickets/`, PAS `shared/ui`, car il dépend du domaine ticket + gateways DI (shared/ui = design system pur). Conforme à tous les autres overlays (SprintManager, MemoryEditor…). Seul `zIndex.ts` (niveau design-system) est dans shared/ui.
+2. **`TicketPickerResult.id`/`number`** : `ticket_list`/`TicketSummary` ne portent NI `id` NI `number`. Résolus par un `ticket_read` unique **à la sélection** (`useTicketSearch.resolve`). `number` serait dérivable du ref mais `id` exige la lecture. → contrat `{ref,id,number,title,status,priority}` respecté sans nouveau endpoint. Écart backend candidat : ajouter id/number au summary (dette basse).
+3. **`zIndex.ts` provisoire** : lot A (#16) introduit le canonique en parallèle. Valeurs alignées sur l'échelle figée (menuDropdown=40, floatingWindow=50, floatingWindowNested=60, toast=70). **À réconcilier au merge** (garder un seul module). Picker monté à `floatingWindowNested=60`.
+
+## Notes d'impl
+- G3-bis respecté : `cursor` traité en token opaque (jamais construit/incrémenté ; relayé verbatim via `loadMore`).
+- `excludeRefs` filtré client-side après réception de page.
+- `useTicketSearch` léger (pas de groupement sprint, pas de souscription events, debounce 200ms) — ne réutilise pas `useTickets`.
+- `TicketFacetsBar` = recherche + facettes statut/priorité (labels aria préservés : `search tickets`, `filter status …`, `filter priority …`, `clear filters`). Le select assignee reste dans `TicketsPanel` (hors périmètre picker).
+- Focus-trap inline (Tab cycling + Escape + restore focus) car aucun util partagé n'existe ; G5 respecté (montage niveau chrome par le consommateur #17/#19).
+- `selectionMode:"multi"` câblé de façon extensible (footer réservé) mais non actif en V1.
+
+QA repasse derrière. Consommateurs #17 (link) et #19 (sprint) importent `TicketPicker` depuis `@/features/tickets`.

.ideai/memory/ticket25-assistant-sandbox-eacces-rootcause.md

@@ -0,0 +1,11 @@
+---
+name: ticket25-assistant-sandbox-eacces-rootcause
+description: Root cause et contrat de fix du EACCES (os error 13) au spawn de la CLI d'un assistant de ticket — le preset SandboxPlan::project_read_only handle la classe exec Landlock.
+metadata:
+  type: reference
+---
+**Symptôme** : ouvrir un assistant de ticket (Codex ou Claude), premier message ⇒ `process error: agent session start failed: <cli>: Permission non accordée (os error 13)`. Indépendant de la CLI.
+
+**Root cause** : `OpenTicketAssistant::execute` (`application/src/ticket_assistant.rs:97`) fabrique un plan bespoke via `SandboxPlan::project_read_only` (`domain/src/sandbox.rs:153`) = grant **RO** sur `project_root` + RW sur le run_dir, posture `Deny`. Dans l'adapter Landlock (`infrastructure/src/sandbox/landlock.rs:70`), un grant RO *handle* la classe read, et `AccessFs::from_read(V1)` **inclut `AccessFs::Execute`**. Le binaire CLI vit hors du project root ⇒ `execve` refusé ⇒ EACCES au `spawn()` sandboxé (`process.rs:248`). Le chemin workspace n'a pas le bug car son plan vient de `compile_sandbox_plan` sous posture `Allow`/write-only ⇒ l'adapter no-op ou ne handle que write, read/exec restent ouverts. Piège déjà documenté dans l'adapter (« enrichment is the launch-path's concern LP4-2 »).
+
+**Fix (backend-pur, zéro port/DTO)** : remplacer le preset par un **write-fence** — ne jamais handle read/exec (pas de grant RO), handle write seul, RW-grant = run_dir + state/home CLI + temp, posture Deny ⇒ écriture projet refusée, binaire/libs/home lisibles-exécutables. Fallback sûr : passer `None` à `factory.start` pour la surface ticket (garde policy MCP + projection advisory). Garde-fous fonctionnels réels = policy MCP `idea_ticket_read/update*` + LP3, pas l'OS-sandbox. Lié à [[ui-rework-sprint-scoping-contracts]].

.ideai/memory/ticket28-f1-frontend-delivered.md

@@ -0,0 +1,17 @@
+---
+name: ticket28-f1-frontend-delivered
+description: Lot F1 du ticket #28 livré sur feature/ticket28-firstrun-detect-hang — invariant busy/detectProfiles, flag detecting, timeout UI, test de non-régression.
+metadata:
+  type: reference
+---
+Lot **F1** (frontend) du bug #28 implémenté sur `feature/ticket28-firstrun-detect-hang` (non committé, Git s'en charge).
+
+**Invariant posé** : dans `frontend/src/features/first-run/useFirstRun.ts`, le retour de `busy` à `false` ne dépend d'aucun appel à `detectProfiles`. `busy` n'entoure plus que `firstRunState()` (reload) et `configureProfiles()` (finish). Toute future régression qui remet un `await profile.detectProfiles(...)` sur un chemin gouvernant `busy` re-gèle le wizard.
+
+**Mécanisme** : `runDetection(candidates, { preselect, reportError })` factorise auto-détection et bouton manuel. Le flag `detecting` est relâché par un `setTimeout(DETECT_TIMEOUT_MS = 3_000)`, **jamais** par la promesse — car le `finally` d'un `await` sur une promesse jamais settled (panic Rust ⇒ pas de réponse IPC) n'est jamais atteint. Un compteur `detectRun` invalide les rounds périmés (re-clic, unmount).
+
+**Piège UI à retenir** : `<Button loading>` implique `disabled` dans le design system (`shared/ui/Button.tsx:46`). Donc `detecting` ne peut pas être surfacé via `loading` sur les boutons Save/Detect sans réintroduire le grisage — il est rendu comme un `role="status"` « Detecting… » séparé.
+
+**Point de vérité QA** : `FirstRunWizard.test.tsx`, describe « detection that never answers (ticket #28) », gateway `HangingDetectGateway` dont `detectProfiles` renvoie `new Promise(() => {})`. Vérifié à teeth : en réintroduisant `setBusy(true); await runDetection(...)` dans `reload`, 2 des 3 tests échouent avec exactement le symptôme du ticket.
+
+Vert : `npx vitest run` 59 fichiers / 569 tests, `npx tsc --noEmit` exit 0. Pas de lint dans ce projet (aucun eslint config ni script). F1 débloque l'UI mais **B1 (DevBackend, `AgentRuntime::detect` sync→async) reste requis** pour que la détection remonte réellement un résultat.

.ideai/memory/ticket28-firstrun-detect-hang-scoping.md

@@ -0,0 +1,19 @@
+---
+name: ticket28-firstrun-detect-hang-scoping
+description: Cadrage hexagonal du bug bloquant first-run (#28) — panic block_on imbriqué dans detect + découplage busy/détection, contrats et point de vérité QA.
+metadata:
+  type: reference
+---
+Bug high #28 (build 0.3.0 / develop 3c6cd04) : au first-run, « Save and continue » ET « Detect installed CLIs » restent grisés → wizard impossible à terminer.
+
+**Cause racine unique (bloquante) — CONFIRMÉE source :** `AgentRuntime::detect` est resté `fn` synchrone (`domain/src/ports.rs:754`, impl `infrastructure/src/runtime/mod.rs:182`) alors que le trait est déjà `#[async_trait]`. L'impl bridge le spawner async via `futures_block_on`/`block_on` (mod.rs:228-237), appelé DANS la commande async Tauri `detect_profiles` → `DetectProfiles::execute` (async) → `detect()` sync sur la même task → tokio panic « Cannot start a runtime from within a runtime ». Un panic dans une commande async Tauri = **aucune réponse IPC** → promesse `invoke` jamais résolue/rejetée → le try/catch interne (`useFirstRun.ts:79-90`, n'attrape que les rejets) ne l'attrape pas → `finally` jamais atteint → `busy` figé true → boutons `disabled: vm.busy` grisés à vie. Se déclenche au 1er profil sondé, toute machine. Déclencheur nouveau de #14 : auto-détection à l'ouverture dans `reload`.
+
+**Cause secondaire (NON bloquante) :** profil `ollama-openai-compatible` (command `openai-compatible`, `detect:None`) → fallback `openai-compatible --version` (binaire absent) → `available:false` erroné (spawn échoue vite, pas de hang). Endpoint HTTP sondé comme un CLI = catégorie-fausse. base_url dispo via `HttpChatConfig` (http://localhost:11434/v1). Précédent réutilisable : `infrastructure/src/store/embedder.rs:401 detect_ollama` (reqwest, timeout 800ms, feature vector-http).
+
+**Fix figé — Backend (DevBackend) :** B1 promouvoir `detect` en `async fn` (supprimer futures_block_on entièrement), maj `DetectProfiles::execute` (.await) + commande. B2 `tokio::time::timeout` borné par probe. B3 brancher endpoint-kind (chat_http / StructuredAdapter::OpenAiCompatible) → probe HTTP best-effort borné de base_url (jamais d'erreur dure) ; CLI-kind = `detection_spec` INCHANGÉ (zéro-régression Claude/Codex). Aucun nouveau port/adapter.
+
+**Fix figé — Frontend (DevFrontend) :** F1 découpler `busy` de la détection : `busy` n'entoure que `firstRunState()`, relâché dès rendu des lignes. Auto-détection = étape détachée non bloquante suivie par un flag distinct `detecting` (ne grise pas Save), avec timeout UI (~3s). Invariant : retour de busy à false ne dépend JAMAIS de detectProfiles.
+
+**Contrats :** port `AgentRuntime::detect` sync→async (validé Architecture). DTO detect_profiles INCHANGÉ (available:bool). Catalogue ollama : detect reste None, détection décidée par nature endpoint.
+
+**Point de vérité QA :** Backend = test `#[tokio::test]` multi-thread sur DetectProfiles::execute (échoue au panic sur code actuel, passe après B1) + endpoint sans spawn CLI + CLI Claude/Codex inchangé. Frontend = RTL avec mock detectProfiles jamais résolu → Save+Detect actifs dès firstRunState. Live = first-run machine sans Claude/Codex, Ollama coché, boutons actifs, Save termine (rebuild AppImage obligatoire). F1 seul débloque déjà ; B1 supprime la cause racine ; les deux requis pour vert.

.ideai/memory/ticket4-announcements-frontend-f1f2f3.md

@@ -0,0 +1,18 @@
+---
+name: ticket4-announcements-frontend-f1f2f3
+description: Topologie du frontend des annonces inter-agent (store borné, preview demandeur filtré requester, overlay cible piloté par le busy/idle par agent) — réintégré sur base develop.
+metadata:
+  type: project
+---
+Branche `feature/agent-live-announcements` (base develop `ebd992e`, non commité). Frontend réintégré depuis `backup/announcements-work-20260704`. Feature `frontend/src/features/announcements/` :
+- `announcementsStore.ts` : index pur `byTarget[target][ticketId]->Announcement[]`, `appendAnnouncement` borné (cap 50), `purgeAllForTarget` (au busy:false), sélecteurs target/requester. Éphémère, jamais persisté. (`purgeTurn` du backup RETIRÉ — plus de signal final sur develop.)
+- `AnnouncementsProvider.tsx` (monté dans App.tsx) : 1 abonnement `system.onDomainEvent`. Deux signaux : CONTENU = `agentAnnouncement`→append ; CYCLE DE VIE = map `busy` par agent, seule autorité de montage/retrait, alimentée par `agentBusyChanged{agentId,busy}` + hydratée du read-model `ProjectWorkState.agents[].busy` via `useHydrateAgentBusy(projectId,agentId)` (seed « si absent » → event live gagne). `busy:false`→purgeAllForTarget. Hooks `useTargetAnnouncements` (active=busy[target]), `useRequesterAnnouncements`, `useHydrateAgentBusy`. Hors provider = store inerte.
+- F3 `TargetAnnouncementsOverlay(projectId,agentId)` monté dans **`LayoutGrid` LeafView** (PAS ConversationCell — absent sur develop ; la cellule agent est le PTY `TerminalView`). Overlay `pointer-events-none`, z-20, au-dessus du write-portal overlay existant. F2 `AnnouncementsPreview` par ligne d'`AgentsPanel` (requester==a.id).
+
+ADAPTATION develop appliquée : `agentTurnEvent{final}` N'EXISTE PAS sur develop → branche de purge retirée du provider, type NON réintroduit dans domain, 2 tests agentTurnEvent supprimés. Autorité unique F3 = busy. Confirmé présents sur develop : `agentBusyChanged{agentId,busy}` (domain/index.ts) et `AgentWorkState.busy: {state:"idle"}|{state:"busy";ticket;sinceMs}`. DTO annonce backend confirmé (events.rs, test JSON à events.rs:927) : `{type:"agentAnnouncement",projectId,requester("user"|agentId),target,ticketId,text,atMs}` — mirroir ajouté dans domain/index.ts.
+
+Exclusion des voiles (arbitrage [[ticket4-overlay-composition-leafview]]) : le voile write-portal (injection PTY) et l'overlay F3 partagent le conteneur relatif du LeafView. Prédicat pur exporté `shouldShowWritePortalVeil(agentPinned, writePortalOverlay, busyActive) = agentPinned && overlay && !busyActive` ; F3 se gate sur le même `busyActive` (`useTargetAnnouncements(agentId).active`, remonté au LeafView). Résultat : exactement UN voile, F3 prioritaire. Purement visuel — `portal.isSuspended()`/l'injection PTY (TerminalView) INCHANGÉS. Testé exhaustivement (table de vérité) dans `overlayExclusion.test.ts`.
+
+Écarts tranchés à signaler : (1) F3 hébergé dans la cellule PTY (LeafView) faute de ConversationCell ; (2) busy est l'autorité brute : sur develop busy vient du mediator (délégations/inter-agent), pas du typing PTF humain, donc proxy correct, mais surveiller un éventuel over-trigger ; (3) F2 filtre requester seul (pas de ticketId par ligne) = garde anti-fuite.
+
+Build vert, 51 fichiers / 481 tests vitest verts.

.ideai/memory/ticket4-overlay-composition-leafview.md

@@ -0,0 +1,25 @@
+---
+name: ticket4-overlay-composition-leafview
+description: Règle de composition des deux voiles plein-cellule de LeafView (write-portal injection PTY vs F3 annonces busy) — exclusion mutuelle avec priorité F3, arbitrée pour éviter le double voile.
+metadata:
+  type: reference
+---
+Arbitrage layout Architect 2026-07-04 (branche feature/agent-live-announcements, base develop ebd992e, 481 tests verts).
+
+**Problème vérifié :** LeafView héberge DEUX voiles plein-cellule inset:0 dans le même conteneur relatif :
+- write-portal (LayoutGrid.tsx:841, zIndex:4, rgba(0,0,0,0.45), « Un agent est en train de parler… ») = délégation injectée dans le PTY de l'agent (§20.3, flag `overlay` de useWritePortal).
+- F3 TargetAnnouncementsOverlay (z-20, bg-canvas/85, « …en train de LUI parler… » + réflexions) = agent busy (agentBusyChanged mediator).
+Ils rendent le MÊME événement depuis deux signaux et montent ENSEMBLE sur le chemin d'injection inter-agent (overlay+busy) → double voile empilé + bannières dupliquées = rendu cassé, chemin nominal.
+
+**Décision (DevFrontend, layout, zéro backend) :** exclusion mutuelle, un seul voile à la fois, priorité F3 :
+- busy(agent) → F3 seul ; voile write-portal gated `agentId!=null && overlay && !busyActive`.
+- sinon overlay → write-portal seul (repli fenêtre sans busy).
+- jamais les deux.
+Sécurité : on ne touche que le visuel ; la suspension des frappes (portal.isSuspended(), TerminalView.tsx:182) reste ; F3 est pointer-events-none.
+
+**Couplage point 3 :** F3 DOIT rendre la bannière sur busy même à 0 annonce (déjà: if(!active) return null, TargetAnnouncementsOverlay.tsx:56), car F3 absorbe le voile write-portal — une garde « ≥1 annonce » rouvrirait le trou d'indication. Pas de garde.
+
+**F2 (point 4) :** filtre requester==id de ligne suffit en V1 (isolation fil partagé) ; ticketId optionnel dormant.
+**F3 hébergement (point 1) :** conteneur LeafView validé (pas de ConversationCell sur develop).
+
+Liens : [[ticket4-restart-on-develop-ebd992e]], [[ticket4-f3-overlay-driven-by-agentbusychanged]], [[inter-agent-live-context-shared-per-agent]].

.ideai/memory/ticket4-restart-on-develop-ebd992e.md

@@ -0,0 +1,20 @@
+---
+name: ticket4-restart-on-develop-ebd992e
+description: Cadrage du redémarrage des annonces inter-agent sur la base pré-canonique develop ebd992e — ce qui existe, l'écart live, la réutilisabilité du backup et le découpage B/F.
+metadata:
+  type: reference
+---
+Redémarrage #4 sur base réalignée main=develop=feature/background=feature/agent-live-announcements=ebd992e (pré-canonique). Vérifié sur le dépôt le 2026-07-04.
+
+**Signaux sur develop :**
+- Émission intermédiaire : AUCUNE. codex.rs draine via run_turn BATCH (process.rs:268/321 lit ligne-à-ligne mais collecte en Vec, renvoie à EOF ; codex.rs:260 Box::new(events.into_iter())). structured.rs:266-271 jette TextDelta/ToolActivity/Heartbeat, ne renvoie que Final.
+- Busy PAR AGENT : PRÉSENT ET COMPLET. DomainEvent::AgentBusyChanged{agent_id,busy} (domain/events.rs:171), autorité mediator (infrastructure/input/mod.rs:433), relay (app-tauri/events.rs:484), front event domain/index.ts:22 + read-model agents[].busy {state,ticket,sinceMs} (:220,304) réconcilié reboot. ⇒ autorité overlay F3 dispo telle quelle.
+- Fix Final : PRÉSENT (62915ee) mais dégrade les agent_message intermédiaires en ToolActivity{label} en JETANT leur texte, et reste batch → inexploitable pour annonces.
+
+**Écart live (faisable SANS moteur canonique) :** run_turn lit déjà incrémentalement ; le batch n'est qu'un artefact de sa signature ->Vec. Ajouter un tap Option<mpsc::Sender<String>> dans run_turn/drain/drain_sandboxed (boucle existante) ; l'orchestrateur (qui détient requester/target/ticket) publie DomainEvent::AgentAnnouncement au fil de l'eau. Thread Landlock n'envoie que des lignes brutes ; publication bus hors thread. Pas de spawn_turn/AgentTurnEvent/ConversationId.
+
+**Réutilisabilité backup (backup/announcements-work-20260704, 691b2ce) :** frontend features/announcements/ (store borné, provider, AnnouncementsPreview=F2, TargetAnnouncementsOverlay=F3) réutilisable ; F3 sur busy = intact sur develop. Dépend d'agentAnnouncement{requester,target,ticketId,text,atMs} (absent→B) et agentTurnEvent{final} (absent, secondaire → RETIRER du store). Backend backup non réutilisable (canonique) ; contrat/attribution repris.
+
+**Découpage :** B1 domaine/appli (ReplyEvent::Announcement + DomainEvent::AgentAnnouncement + publish au drain) ; B2 infra = CŒUR (tap mpsc process.rs + codex émet Announcement{text} live) ; B3 relay/DTO ; F1 store (–hook final) ; F2 preview (filtre ticketId+requester==self) ; F3 overlay (réutilisé, busy seul autorité).
+
+Liens : [[ticket4-f3-overlay-driven-by-agentbusychanged]], [[ticket4-announcements-reintegration-topology]], [[inter-agent-announcements-feature-and-codex-final-bug]], [[inter-agent-live-context-shared-per-agent]].

.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/ticket54-f1-model-download-overlay-frontend.md

@@ -0,0 +1,15 @@
+---
+name: ticket54-f1-model-download-overlay-frontend
+description: Overlay plein-cellule de préparation du serveur modèle local + progression (barre/%/bytes/source), corrélation factorisée, priorité de voile.
+metadata:
+  type: reference
+---
+Ticket #54 livré et vert côté frontend (F1 = overlay, F2 = progression).
+
+**Contrat** : `ModelServerStatus.downloading { downloadedBytes|totalBytes|percent|source: number|string|null }` (`frontend/src/domain/index.ts`), miroir exact de `ModelServerStatusDto` (`crates/app-tauri/src/events.rs`). Event `modelServerStatusChanged` passé tel quel — pas de mapping de désérialisation.
+
+**Factorisation** dans `frontend/src/features/agents/modelServerLaunch.ts` : `correlateModelServerStatus` (chaîne `agentId→profileId→opencode.localModelServerId→serverId`), `modelServerOverlayText` (titre+gating de voile), `useModelServerLaunchState(projectId)` (source autonome pour LeafView), et F2 : `formatBytes` (SI base 1000 : o/Ko/Mo/Go) + `describeModelServerDownload` → `{percent(clamp 0..100 ou null=indéterminé), bytesLabel, source}` (null hors `downloading`). AgentsPanel réutilise le helper.
+
+**Overlay** dans `LeafView`/`LayoutGrid.tsx` (`data-testid=model-server-overlay`, `zIndex CELL_Z.veil`) : titre + barre `role=progressbar` (aria-valuenow seulement en déterminé, sinon barre indéterminée via keyframe `model-server-indeterminate` dans `theme.css`) + label `"X % · A Mo / B Mo"` + ligne source HF. `starting`/`probing` = titre seul, pas de barre. **Priorité : voile modèle au-dessus** des voiles write-portal + F3 (les deux gatés sur `!modelServerOverlay`). Voir [[ticket4-overlay-composition-leafview]].
+
+Tests : `LayoutGrid.modelServerOverlay.test.tsx` (F1+F2, dont multi-cellules & indéterminé) + unitaire pur `modelServerLaunch.test.ts`. Non-régression `src/features/agents src/features/layout` = 202 verts ; `npx tsc --noEmit` clean.

.ideai/memory/ticket56-visibleelsewhere-derives-from-layout.md

@@ -0,0 +1,19 @@
+---
+name: ticket56-visibleelsewhere-derives-from-layout
+description: Fix frontend du sélecteur d'agent : la désactivation « visible ailleurs » doit venir du layout courant, pas du dernier nodeId du live registry.
+metadata:
+  type: reference
+---
+Bug #56 : agent X affiché en cellule A → A bascule sur Y → X désactivé (« visible ailleurs ») en cellule B alors que X n'est plus affiché nulle part.
+
+Cause : le live registry garde X→nodeId A même après le swap ; `LayoutGrid.visibleElsewhere` lisait `live.nodeId` comme « affiché ici ».
+
+Fix (frontend pur, ne tue pas la session) dans `frontend/src/features/layout/LayoutGrid.tsx` :
+- `visibleElsewhere(candidate)` dérive du **layout courant** : truthy uniquement s'il existe une feuille visible ≠ cellule courante avec `leaf.agent === candidate`. Retourne `{ nodeId }`.
+- `backgroundLive` utilise `!visibleElsewhere(candidate)` au lieu de `!visibleNodeIds.has(live.nodeId)` ; garde `live.nodeId === id` (anti-boucle self-launch).
+- onChange du select : même dérivation ; sélection inchangée (attachLiveAgent si sessionId sinon setCellAgent).
+- Prop `visibleNodeIds` supprimé (devenu mort) de tout le threading LayoutGrid→NodeView→Split/Grid/Leaf.
+
+Invariant préservé : agent réellement épinglé dans une cellule visible reste NON sélectionnable ailleurs.
+
+Piège de test : un test qui mocke `listLiveAgents` avec un nodeId visible mais **sans** épingler l'agent dans ce leaf ne désactive plus rien — il faut `setCellAgent` réel. Tests dans `singletonAgent.test.tsx` (describe « ticket #56 » + ajustement R0d). Suite frontend : 706 verts.

.ideai/memory/ticket7-f2-delegated-limit-no-agentratelimited.md

@@ -0,0 +1,16 @@
+---
+name: ticket7-f2-delegated-limit-no-agentratelimited
+description: Écart backend ticket #7/F2 — le rendez-vous délégué n'émet pas AgentRateLimited ni n'arme la reprise pour la cible limitée.
+metadata:
+  type: project
+---
+
+Ticket #7, volet inter-agent. Constat F2 (frontend DevFrontend) sur `feature/session-limit-interagent`.
+
+Le chemin délégué (rendez-vous headless) **n'appelle jamais** `session_limit_service.on_rate_limited(target, …)`. Dans `crates/application/src/orchestrator/service.rs:1876-1915`, la branche `TargetRateLimited` publie **uniquement** `DomainEvent::DelegationRateLimited{requester, target, resets_at_ms}` puis retourne `AppError::TargetRateLimited`. Les deux seuls sites de `on_rate_limited` sont les chemins humains PTY/chat (`crates/app-tauri/src/commands.rs:1409` et `:1535`).
+
+**Conséquence** : quand la cible B est limitée **via une délégation**, aucun `AgentRateLimited`/`AgentResumeScheduled` n'est émis pour B ⇒ le badge mono-agent de B (piloté par `limitByAgent` dans `useAgents`) ne s'affiche pas et aucune reprise auto n'est armée pour B. Contredit le commentaire de `crates/app-tauri/src/events.rs:370-372` (« the target resume flow is surfaced by the existing agent limit events »).
+
+**Why:** F2 supposait « même flux AgentRateLimited ». Le rendu frontend du badge est sain (re-render + bouton Annuler OK) ; l'écart est backend.
+
+**How to apply:** correction = backend (appeler `on_rate_limited` pour la cible dans la branche rendez-vous, avec node/conversation adéquats). Ne PAS dériver le badge de B depuis `delegationRateLimited` côté front : cet event ne porte ni sémantique de reprise armée ni node_id/conversation_id pour armer le réveil → inventerait un contrat. Le côté DEMANDEUR (A) est, lui, bien couvert par F1 (`suspendedDelegationsByRequester`). Voir [[session-limit-handling-design]].

.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/tickets-frontend-v1-done.md

@@ -0,0 +1,15 @@
+---
+name: tickets-frontend-v1-done
+description: État du frontend du système de tickets — livré, vert, décisions de contrat clés.
+metadata:
+  type: project
+---
+Frontend V1 du système de tickets livré sur `feature/issue-ticket-system` (non commité, attend QA/Git). Build + 459 tests verts.
+
+Décisions figées :
+- Port nommé `TicketGateway` (pas IssueGateway) — aligné sur le wire `ticket_*`/`TicketDto` et le terme visible « ticket ».
+- Statut/priorité côté UI passent par `ticket_update` : `ticket_update_status`/`ticket_update_priority` ne sont PAS des commands Tauri (MCP-only, non enregistrées dans `lib.rs`).
+- Conflit de version = `code:"INVALID"` + message contenant `"issue version conflict"` (détection par message, pas de code dédié). Voir `isTicketVersionConflict`.
+- F7 = `#ref` cliquables + linkification desc + bouton clipboard « Travaille sur le ticket #N : <titre> » (pas d'écriture terminal directe en V1).
+
+Surface : `features/tickets/` (panel liste + overlay détail/carnet/liens/assign), onglet sidebar « Tickets » dans ProjectsView entre Work et Agents, `MockTicketGateway` émet les events `Issue*`. Voir [[checkpoint-issue-ticket-backend-v1-done]] et [[issue-ticket-system-design]].

.ideai/memory/tickets-t3-frontend-validation-verdict.md

@@ -0,0 +1,15 @@
+---
+name: tickets-t3-frontend-validation-verdict
+description: Verdict de validation frontend du fix T3 (projection backgroundTasks par agent) sur feature/background-tasks-first-class — vert, avec 3 désalignements de contrat mineurs.
+metadata:
+  type: reference
+---
+Validation frontend du fix T3 (ticket #1), branche `feature/background-tasks-first-class`, 2026-07-03.
+
+**Verdict : vert.** `npx vitest run` = 460/460, `npm run build` (tsc --noEmit + vite) OK. Le front était déjà câblé pour Cancel/Retry ; contre le vrai payload backend le mapping d'états et l'activation des boutons fonctionnent.
+
+**Contrat backend réel** (`crates/app-tauri/src/dto.rs::AgentBackgroundTaskStateDto`, camelCase) : `taskId, kind, state, exitCode?, summary?, stdoutTail?, stderrTail?, createdAtMs, updatedAtMs`. `state` ∈ queued|running|waiting|completed|failed|cancelled|expired ; `kind` ∈ command|headlessRendezvous|sessionResume|maintenance. **Pas** de `status`, `ownerAgentId`, `projectId`, ni `finishedAtMs`.
+
+**Fait :** FE-1 rendu explicite `queued`/`waiting`→`pending` dans `normalizeBackgroundStatus`. FE-2 ajout d'un test sur le vrai shape dans `src/features/workstate/workstate.test.tsx` (le mock passe par le vrai `normalizeProjectWorkState`, donc pas de faux-vert possible).
+
+**Écarts de contrat à arbitrer (dette, panneau non modifié) :** (1) `ProjectWorkStatePanel.tsx` trie sur `finishedAtMs` jamais émis → tri retombe sur taskId, non chronologique ; (2) `summary` backend non porté par `BackgroundCompletion` → ignoré ; (3) `ownerAgentId`/`projectId` absents du payload par-agent (inoffensif : fallback = agentId). Voir [[workstate-background-tasks-projection-fix]] et [[b8-in-app-trigger-run-in-background]].

.ideai/memory/tickets-v1-e2e-validated-qa.md

@@ -0,0 +1,15 @@
+---
+name: tickets-v1-e2e-validated-qa
+description: Verdict QA du système de tickets V1 sans attachments sur feature/issue-ticket-system — vert de bout en bout, avec la seule réserve du typage de conflit côté UI.
+metadata:
+  type: reference
+---
+Validation QA de bout en bout du système de tickets **V1 (sans attachments)** sur `feature/issue-ticket-system` (backend commité `8de7be0`, frontend non commité). **Verdict : OK.**
+
+**Preuves réelles :**
+- `cargo build --workspace` OK. Tests verts sur domain/application ; infrastructure et app-tauri verts **sauf la dette pré-existante déclarée** (`orchestrator_watcher::ask_request_surfaces_reply_alongside_detail` + `app-tauri state::mcp_e2e_loopback_tests::*`, tous `Elapsed(())` du rendez-vous, sans rapport avec les tickets). Aucun échec imputable aux tickets.
+- Frontend : `npm run build` OK (tsc+vite), `npm test` = **459 passed / 49 files**.
+
+**Invariants prouvés par tests :** `#N` séquentiel jamais réutilisé (`allocator_never_reuses_numbers`) ; create→read round-trip ; carnet remplaçable & scoped `.ideai/tickets/N/carnet.md` ; pas de self-link (`IssueError::SelfLink`, `domain/issue.rs`) ; assignation agent connu seulement (`create_issue_rejects_unknown_assignee`) ; concurrence optimiste (`update_issue_maps_version_conflict`, `IssueStoreError::VersionConflict`) ; énums fermés statut/priorité.
+
+**Réserve non bloquante (dette technique) :** le conflit de version est détecté côté **front** par fragment de message (`message.includes("version conflict")`, `frontend/src/adapters/ticket.ts`, `useTicketDetail.ts`), s'appuyant sur `domain/ports.rs` `#[error("issue version conflict: …")]`. Un code typé `"versionConflict"` existe DÉJÀ mais uniquement sur la surface MCP (`app-tauri/src/tickets.rs:942`) ; le chemin Tauri command renvoie `INVALID`. Recommandation : propager le code typé dans l'enveloppe d'erreur des `ticket_*` commands et brancher l'UI sur `error.code`. Comportement actuel correct et testé, donc 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/ui-rework-sprint-delivered-tickets-21-22-23.md

@@ -0,0 +1,19 @@
+---
+name: ui-rework-sprint-delivered-tickets-21-22-23
+description: memory note ui-rework-sprint-delivered-tickets-21-22-23
+metadata:
+  type: project
+---
+Sprint « UI rework » (order 1) bouclé le 2026-07-07. Les 4 premiers tickets (#16/#17/#18/#19) étaient déjà mergés ; les 3 derniers viennent d'être produits et intégrés. Cadrage : [[ui-rework-sprint-tickets-21-22-23-scoping]].
+
+## Livré (tous verts QA par exécution réelle, mergés --no-ff sur develop)
+- **#21** tri des tickets (B+F) — merge `37bf7d4`. Backend : `TicketListQuery.sort?:{field:"number"|"priority"|"status"|"title";direction:"asc"|"desc"}`, appliqué avant pagination, tie-break systématique par `number` croissant. Ordres sémantiques : priority low<medium<high<critical ; status open<inProgress<QA<closed ; title casse-insensible. `sort` absent = comportement historique. Frontend : contrôle « Trier par… » dans `TicketFacetsBar` (partagé TicketsPanel + TicketPicker), `sort` dans query+queryKey (reset pagination), curseur reste opaque (G3-bis).
+- **#22** docking de views (F pur) — merge `2323a71`. Nouvelle primitive `shared/ui/DockRegion` + modèle `features/projects/viewPlacement.ts` : `ViewPlacement = "closed"|"floating"|{dock:"left"|"right"}` par PanelId, invariant un-seul-slot. Ne réutilise NI FloatingWindow NI LayoutTree terminaux (monté chrome-level ProjectsView).
+- **#23** fenêtres système (B+F) — merge `47b1d64` (HEAD develop). Backend app-tauri : commands `open_view_window({panel,projectId})→{label,url,alreadyOpen}` et `close_view_window(...)→{label,closed}`, vraie WebviewWindow chargeant `index.html?panel=&project=`, registre anti-doublon (label `view-{panel}-{projectIdSansTirets}`), event unique `view-window://lifecycle` payload `{kind:"opened"|"focused"|"closed",panel,projectId,label}`, capability étendue à `view-*`. Frontend : port `WindowGateway` (adapter Tauri + mock), entrée panel-only `app/ViewWindow.tsx` routée dans `main.tsx`, `ViewPanelBody` partagé, `ViewPlacement` étendu à `"detached"`, menu Window + bouton ⤢, garde no-direct-invoke.
+
+## Dette basse restée ouverte (hors périmètre, non bloquante)
+- Curseur `ticket_list` toujours offset non opaque/stable (cf. [[ui-rework-sprint-scoping-contracts]]) — non soldée par #21.
+- Persistance restore-au-redémarrage du docking #22 et du placement détaché #23 : follow-up backend différé (V1 = placement éphémère useState).
+
+## État Git
+develop @ `47b1d64` ; branches feature/ticket21-22-23 supprimées (mergées). Rien de sortant, `main` intact. Release `develop→main` en attente de validation utilisateur.

.ideai/memory/ui-rework-sprint-scoping-contracts.md

@@ -0,0 +1,23 @@
+---
+name: ui-rework-sprint-scoping-contracts
+description: Frontières hexagonales et contrats figés du sprint UI rework — les 4 tickets sont frontend-purs, la popup TicketPicker #18, l'échelle z-index et le curseur opaque.
+metadata:
+  type: reference
+---
+Sprint « UI rework » (order 1), cadré 2026-07-06. Les **4 tickets sont frontend-purs** : aucun nouveau port/read-model/endpoint.
+
+**Fait clé** : filtrage/recherche tickets déjà backend-driven via `TicketGateway.list(projectId, TicketListQuery{statuses[],priorities[],assignedAgentId,text,limit,cursor})` (ports/index.ts:717) → adapter transmet à `ticket_list`. Client ne fait que le groupement par sprint. #18 réutilise ce contrat, pas d'endpoint dédié.
+
+**G4 (contrat ticket_list) levé pour B** après revue DevBackend : statuses/priorities OK (OR intra / AND inter). Deux écarts en DETTE BASSE : (a) `text` ne matche pas `#ref` (tickets.rs:681, issues.rs:322/326/465) ; (b) `cursor` = offset numérique non opaque/non stable inter-pages (tickets.rs:1231). Acceptable pour picker single-select court.
+
+**G3-bis (garde non-breaking)** : TicketPicker/useTicketSearch traitent `cursor` comme token OPAQUE — ne jamais le construire/incrémenter, ne relayer que le cursor de la page précédente. Migration curseur opaque backend = zéro changement frontend.
+
+**Base de code** : pas de routeur ni store global (navigation = useState local App.tsx + ProjectsView.tsx, sidebar inline ProjectsView.tsx:224). Aucune primitive Modal/Portal partagée ; ~7 features hand-roll `fixed inset-0 role=dialog` z-50/z-[60]. Pas de createPortal. #16 introduit `shared/ui/FloatingWindow` (focus-trap, monté niveau chrome) + `shared/ui/zIndex.ts`.
+
+**Contrat #18 figé** — `TicketPicker` props `{open, projectId, title?, confirmLabel?, selectionMode?:"single"|"multi" (défaut single), excludeRefs?: TicketRef[] (filtré client-side), initialQuery?: TicketListQuery, onSelect(TicketPickerResult|[]), onClose}`. `TicketPickerResult={ref,id,number,title,status,priority}`. Extraire `TicketFacetsBar` (fieldsets statut/priorité + recherche depuis TicketsPanel.tsx) + hook `useTicketSearch` (ne PAS réutiliser useTickets, trop lourd). #17 et #19 consomment en single.
+
+**Échelle z-index figée (G2)** : in-cell inchangé (chrome 2-5, F3 z-20, write-portal z-4, resume z-5) ; chrome full-window menuDropdown=40, floatingWindow=50, floatingWindowNested=60, toast=70.
+
+**Règle intégration (G5)** : fenêtres flottantes/menus montées niveau chrome (ProjectsView/App), JAMAIS dans LayoutGrid/LeafView. Ne pas toucher shouldShowWritePortalVeil ni exclusion write-portal↔F3 (cf. [[ticket4-overlay-composition-leafview]]). Focus-trap obligatoire (xterm garde le focus clavier).
+
+**Ordre** : A(#16) ∥ B(#18) racines → prioriser B (chemin critique #17+#19) ; D(#19) après B ; C(#17) après A+B. Tout DevFrontend ; DevBackend = ticket dette basse (matching #ref + curseur opaque/stable).

.ideai/memory/ui-rework-sprint-tickets-21-22-23-scoping.md

@@ -0,0 +1,39 @@
+---
+name: ui-rework-sprint-tickets-21-22-23-scoping
+description: memory note ui-rework-sprint-tickets-21-22-23-scoping
+metadata:
+  type: project
+---
+Cadrage hexagonal des 3 derniers tickets du sprint « UI rework » (order 1), fait 2026-07-07 par Architect. Les 4 premiers (#16/#17/#18/#19) sont livrés/mergés sur develop — cf. [[ui-rework-sprint-scoping-contracts]]. Ne pas re-cadrer ; produire.
+
+## État de départ vérifié
+- Vues (context/work/tickets/agents/templates/skills/permissions/memory/git) = composants React rendus via menu **View**, pilotés par `openPanel: useState<PanelId|null>` (ProjectsView.tsx:127). UNE seule vue à la fois dans un `FloatingWindow` modal centré (ProjectsView.tsx:497).
+- `FloatingWindow` = overlay MODAL (fixed inset-0, backdrop, focus-trap, z-50), non déplaçable/non redimensionnable, purement présentationnel.
+- LayoutTree terminaux (cellules/LeafView, layout.json via ProjectStore) = domaine DISTINCT ; ne pas confondre avec le placement des vues.
+- `TicketListQuery` (ports/index.ts:717) N'A PAS de sort/order. Pagination RÉELLE (useTicketSearch + loadMore, TicketsPanel.tsx:225 charge 100 puis +100).
+
+## #21 tri tickets (low) — NON frontend-pur : B + F
+Le tri est une préoccupation de QUERY, symétrique du filtrage déjà backend-driven (TicketGateway.list→ticket_list). Comme la liste est paginée, trier client ne trie que les pages chargées → FAUX. Refuser le « frontend-pur ».
+- **B** : étendre `TicketListQuery`/`ticket_list` avec `sort?:{field:"number"|"priority"|"status"|"title"; direction:"asc"|"desc"}`. ORDRE TOTAL déterministe obligatoire (tie-break par number croissant, sinon curseur casse). priority/status = ordre sémantique enum explicite, pas alpha. Défaut absent = comportement actuel (champ optionnel, rétro-compat). Companion recommandé non imposé : solder la dette basse curseur offset non opaque/stable (cf. [[ui-rework-sprint-scoping-contracts]]) — peut rester ticket séparé.
+- **F** : contrôle « Trier par… » dans `TicketFacetsBar` (partagé TicketsPanel + TicketPicker #18). `useTicketSearch` relaie `sort` dans la query, `sort` dans la queryKey (reset pagination). Ne pas toucher le traitement OPAQUE du curseur (G3-bis). Groupement-par-sprint reste client ; tri s'applique intra-groupe.
+- Dépend #16/#18 (livrés). Indépendant de #22/#23.
+
+## #22 Anchor/docking views (medium) — frontend-pur V1 ; persistance = B optionnel différé
+NE PAS réutiliser FloatingWindow (overlay modal) ni LayoutTree terminaux. NOUVELLE primitive de docking chrome-level, en-flux (pas overlay).
+- Frontière : docking = état présentation chrome-level machine-local, distinct du domaine LayoutTree (réservé cellules PTY). Jamais dans LayoutGrid/LeafView (G5).
+- Généraliser `openPanel:PanelId|null` en modèle de placement : `ViewPlacement = "closed"|"floating"|{dock:"left"|"right"}` par PanelId — conçu EXTENSIBLE pour #23 (ajoutera "detached"). Invariant : une vue = exactement un slot. V1 reco : 1 vue ancrée par côté, largeur redimensionnable.
+- **F** : `shared/ui/DockRegion` (colonne verticale resizable gauche/droite du <main>), header titre + bascule flottant↔ancré. ProjectsView remplace openPanel par le placement. Réutilise composants de vue existants tels quels.
+- **B optionnel différé** : persistance restore-au-redémarrage = préférence UI machine-local → store global settings.json/workspace.json (archi §9.2 via ProjectStore), PAS layout.json projet. V1 éphémère (useState) ; persistance = follow-up ticket dédié.
+- Autonome. FOURNIT le modèle de placement dont #23 dépend.
+
+## #23 views en fenêtres système (medium) — impact backend Rust + composition root
+Cas spécialisé du chantier L10 multi-fenêtre (Tauri v2 WebviewWindow, protocole detach, archi §13.3). Avantage vs detach onglet-terminal : vues gateway/read-model-driven, PAS liées à un Channel PTY → nouvelle WebviewWindow ré-instancie le DI et re-souscrit aux gateways, AUCUN transfert d'état lourd.
+- **B (app-tauri)** : command `open_view_window({panel,projectId})` créant une WebviewWindow sur entrée dédiée (URL param ?panel=&project=), lifecycle (focus/close/registre anti-doublon), events cycle de vie (fermeture OS → re-bascule placement). Composition root (di.tsx) : supporter un shell « panneau seul » (mêmes adapters/gateways).
+- **F** : nouveau port `WindowGateway.openViewWindow(panel,projectId)` (+ closeViewWindow) avec adapter Tauri + mock (jamais invoke direct). Entrée panel-only lisant panel/project depuis URL. Menu View : action « Ouvrir dans une nouvelle fenêtre ».
+- Articulation #22 FIGÉE : `ViewPlacement = "closed"|"floating"|{dock:"left"|"right"}|"detached"`. Une vue = soit ancrée soit flottante soit détachée, jamais deux (même invariant un-seul-slot). #23 = ajoute "detached" + plomberie Tauri.
+- DÉPEND du modèle de placement de #22.
+
+## Ordre & dépendances
+- #21 en parallèle, autonome (petit B+F, le plus rapide, chaîne tickets uniquement).
+- #22 AVANT #23 : #22 pose ViewPlacement que #23 étend. #23 d'abord = réinventer puis retravailler.
+- Frontières : #21 seul à toucher domaine tickets (query sort) ; #22 présentation pure (docking ≠ LayoutTree) ; #23 seul à toucher app-tauri/composition root + nouveau port WindowGateway.

.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/memory/workstate-background-tasks-projection-fix.md

@@ -0,0 +1,15 @@
+---
+name: workstate-background-tasks-projection-fix
+description: Décision d'archi pour rendre visibles Cancel/Retry dans le panneau Work — extension du read-model GetProjectWorkState, contrat DTO et borne de livraison.
+metadata:
+  type: reference
+---
+**Défaut** : `AgentWorkState` (`crates/application/src/workstate/mod.rs:140`) ne portait pas les tâches de fond et `GetProjectWorkState` n'avait pas de dépendance `BackgroundTaskStore`. Le panneau Work masque la section (`ProjectWorkStatePanel.tsx:638`, `agent.backgroundTasks.length > 0`) → aucun bouton Cancel/Retry en live. Le frontend était déjà entièrement câblé (`normalizeAgent`/`normalizeBackgroundTask`), il ne manquait que la projection backend.
+
+**Décision (frontière)** : étendre le read-model unique — ajouter `background_tasks: Vec<AgentBackgroundTaskState>` à `AgentWorkState` et brancher `BackgroundTaskStore` via un builder best-effort `with_background_tasks(store)` (calqué sur `with_conversation_sources`), `None` ⇒ zéro régression. **Pas** de fetch séparé côté front (garderait la jointure tâche→agent hors du domaine, casserait l'instantané cohérent, dupliquerait les cycles async). Aucun nouveau port/adapter. `list_background_tasks` (B7) reste comme read-model autonome, hors chemin du panneau.
+
+**Contrat** : `AgentBackgroundTaskState` = miroir de `BackgroundTaskDto` (`dto.rs:2886`) sans owner/project. Projection dans `execute` = union `list_open_for_agent(agent.id)` (per-agent, running/queued/waiting) + `list_undelivered_completions()` (chargé UNE fois avant la boucle, dispatché par `owner_agent_id`, pour failed/cancelled → Retry). Best-effort strict : erreur store ⇒ `Vec::new()` pour l'agent, jamais d'`AppError` (live/busy/tickets intacts).
+
+**Borne V1 assumée** : une tâche terminale **déjà livrée** (wake tiré, `completion_delivered=true`) n'est plus énumérable (droppée des deux listes) → disparaît du panneau ; Retry seulement dans la fenêtre non-livrée. Conforme à la note « retry session-scoped V1 » de `RetryBackgroundTask` (`background/mod.rs:212`). Historique Retry persistant = V2 (ajouterait `list_recent_terminal_for_agent` au port), ticketable si besoin.
+
+**Wiring** : `.with_background_tasks(state.background_task_store.clone())` dans `crates/app-tauri/src/state.rs` (ancre `b7-wiring-anchor-state-rs`) ; le store y est déjà managé (utilisé par `list_background_tasks`). Lié à [[b8-in-app-trigger-run-in-background]], [[b8-command-runner-pty-framing]], [[background-tasks-first-class-design]], [[checkpoint-t1-wake-delivery-bug-fixed-rebuild-pending]].

.ideai/permissions.json

@@ -149,6 +149,82 @@
         ],
         "fallback": "allow"
       }
+    },
+    {
+      "agentId": "c3e0d9d8-df36-4b00-b271-62d8aa78892c",
+      "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"
+      }
+    },
+    {
+      "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

@@ -4,7 +4,14 @@
     {
       "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"
     }
   ]
 }

.ideai/skills/md/86ea97df-1533-47e5-8809-dc2b02242567.md

@@ -0,0 +1,42 @@
+# Skill — Test fonctionnel du rendez-vous inter-agents MCP
+
+Workflow **ré-exécutable et évolutif** pour tester de bout en bout le rendez-vous `idea_ask_agent` ⇄ `idea_reply` d'IdeA, du trivial au plus tordu. À relancer après chaque rebuild qui touche l'orchestration MCP / le backstop / la live-state. **Ce plan évolue** : à chaque nouveau souci rencontré, ajoute/raffine un test Tn et note le défaut dans la section « Journal des défauts ».
+
+## Principe
+- **Main est le demandeur** (`idea_ask_agent`) — test fidèle de « si je donne un message à un agent, il me répond ».
+- Doublé d'**observation externe Bash** :
+  - ponts : `ss -xp | grep idea-mcp` (ESTAB) et `pgrep -af mcp-server` (2 process par requester = pont vivant).
+  - transcripts : `~/.claude/projects/<run-dir-encodé>/*.jsonl` (horodatages **UTC**). Reply réel = `tool_use` idea_reply → tool_result `reply … delivered`. Wedge demandeur = transcript figé sur `tool_use` idea_ask_agent sans tool_result. 1er tour intact = 1re ligne user `parentUuid:null` = `[IdeA · tâche…]`.
+  - placement : `.ideai/layouts.json` (agent présent = cellule visible ; absent = background / node_id None).
+  - live-state : `idea_workstate_read` (last-writer-wins, pas temps réel).
+- Règle structurelle : **binaire qui tourne = AppImage**. Tout fix backend ⇒ **rebuild + relance** d'IdeA (tue Main). Les tests s'enchaînent SANS relance *à l'intérieur d'une même version*. Vérifier avant T1 : `stat` mtime de l'AppImage récent + `git log -1` = HEAD attendu.
+
+## Setup avant T1
+1. Relancer IdeA, ouvrir le projet, **Main visible** (le demandeur).
+2. Garder **2 cellules visibles libres** + lancer **QA et DevFrontend** dans des cellules visibles (cibles chaudes).
+3. Laisser **Architect, DevBackend, Git ARRÊTÉS (froids)** : T3 teste le réveil à froid ; T9 utilise Architect+DevBackend froids.
+
+## Méthode d'exécution
+On lance dans l'ordre, on **note** chaque verdict avec preuve réelle. Si un défaut **bloquant** apparaît : stop, ouvrir le cycle de fix (Architect→Git→DevBackend→QA, ou via subagents si le rendez-vous lui-même est cassé), rebuild + relance, puis **reprise depuis T1**. Un défaut **non bloquant** est consigné au Journal et on peut continuer si l'utilisateur le décide.
+
+## Ordre des tests (trivial → tordu)
+- **T1 — Visibilité outils MCP.** Agent lancé par IdeA voit ses outils sans action manuelle. Vérif : pont ESTAB + 2 mcp-server par requester ; cibles froides = 0 process.
+- **T2 — Cible CHAUDE + idea_reply trivial.** ask(agent chaud, « pong via idea_reply »). Attendu : `pong` inline borné, workstate `done`, pas de busy fantôme.
+- **T3 — Réveil à FROID + idea_reply.** Cible arrêtée. Attendu : pont relancé (nouveau mcp-server), **1er tour non perdu**, reply remonte.
+- **T4 — Cible BACKGROUND (node_id None).** Cible hors layout (sans cellule visible). Attendu : même protocole, multi-tours sans perte.
+- **T5 — NO-REPLY (cible répond en prose, pas d'idea_reply).** Attendu : backstop libère le demandeur en temps borné avec `TargetReturnedNoReply` (retryable), **ET live-state de la cible purgée (pas de busy fantôme)**. Défaut historique #1.
+- **T6 — Délégation MULTI-ÉTAPES puis idea_reply.** Cible lit plusieurs fichiers / lance une cmd PUIS idea_reply. Attendu : **pas de libération prématurée** pendant le travail, rapport final livré. (Piège turn-watcher : backstop tirait au 1er tour interne ~3 s.)
+- **T7 — Tâche LOURDE > plafond** (impl + `cargo test`/clippy). Attendu : extension sur signe de vie OU message clair « cible active, plafond atteint » (≠ faux `-32001`) ; idea_reply tardif non perdu. Plafond `IDEA_ASK_RENDEZVOUS_TIMEOUT_MS` (défaut 600000).
+- **T8 — Délégations PARALLÈLES** (2 cibles en 1 tour Main). Attendu : rendez-vous multiples simultanés, multiplexage pont, 2 réponses distinctes.
+- **T9 — TRANSITIVE A→B→C** (Main→Architect, Architect délègue à DevBackend puis reply à Main). Attendu : rendez-vous imbriqués, 2 attentes simultanées sans deadlock.
+- **T10 — INTERRUPTION/annulation + reconcile reboot.** (a) Main interrompt un ask en vol → `working` cible purgé, pas de cascade, idea_reply tardif non-livrable proprement. (b) Au reboot, orphelins {working,waiting,blocked} & session morte → `idle` + `STALE_AT_RESTART_MARKER` (use case ReconcileLiveState).
+
+## Critère de fin
+Tous les T1→T10 verts avec preuve réelle. Sinon : 1er défaut bloquant = corriger puis reprise T1.
+
+## Journal des défauts (à enrichir au fil des runs)
+- **2026-06-24, run a6ced819 (AppImage 08:15, HEAD 1efe2f1)** — T1→T4 ✅. **T5 partiel** : backstop libère le demandeur en ~24 s (`TargetReturnedNoReply` retryable, wedge demandeur corrigé) MAIS la **live-state de la cible n'est pas purgée** : elle reste `status:"working"` jusqu'au prochain write réussi de la cible (re-délégation non bloquée, busy fantôme atténué mais présent → `idea_workstate_read` ment sur la dispo). Cause : backstop agit côté demandeur, ne réinitialise pas la live-state de la cible sur no-reply. → fix en cours.
+
+## Notes / pièges observés
+- IdeA peut placer une cible réveillée en **background** même quand des cellules visibles sont libres (observé T3/T4).
+- Quand le rendez-vous MCP lui-même est suspecté cassé, **ne pas** orchestrer le fix via `idea_ask_agent` (risque de blocage) : utiliser les subagents natifs de l'orchestrateur pour analyse/fix/rebuild.

.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>
+```