Merge feature/ticket77-paired-devices into develop

Intègre le ticket #77 : l'appairage repose désormais sur des appareils
persistants, nommés et révocables, derrière un code éphémère à usage
unique (TTL 10 min) au lieu d'un code permanent imprimé sur stdout.

Ferme aussi la dette #76 : la normalisation du code passe côté serveur,
là où #75 ne pouvait que la masquer depuis le frontend.

Suites rejouées avant merge, toutes vertes :
- cargo test -p domain -p application -p infrastructure -p web-server :
  exit 0, 89 suites, 1686 tests.
- frontend : 91 fichiers, 848 tests, tsc exit 0.
- garde-fou de bundle : dist = tauri, dist-web = http.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.gitignore

@@ -1,12 +1,19 @@
 # ─── 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
 npm-debug.log*
 yarn-debug.log*
@@ -32,6 +39,18 @@ frontend/coverage/
 # Ephemeral per-agent run directories (isolated PTY cwd + generated convention
 # files), created at activation — not versioned (ARCHITECTURE §9.1 / §14.1).
 .ideai/run/
+# Derived vector store for semantic recall (LOT C / §14.5.3): embeddings of the
+# memory notes, rebuildable from the `.md` source of truth — not versioned.
+.ideai/memory/.index/
+# Runtime file-protocol orchestration requests/responses — transient I/O, not
+# durable project state (curation .ideai §chantier secondaire).
+.ideai/requests/
+# 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
 
 # ─── Editors / OS ───────────────────────────────────────────────────────────
 .idea/
@@ -41,3 +60,8 @@ frontend/coverage/
 *~
 .DS_Store
 Thumbs.db
+# Conversation runtime (handoff distillé + log.jsonl transcript par paire) :
+# é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/agents.json

@@ -1,19 +0,0 @@
-{
-  "version": 1,
-  "agents": [
-    {
-      "agentId": "a6ced819-b893-4213-b003-9e9dc79b9641",
-      "name": "Main",
-      "mdPath": "agents/main.md",
-      "profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
-      "synchronized": false
-    },
-    {
-      "agentId": "dce19c75-9669-4e45-b8de-9950025157da",
-      "name": "Architect",
-      "mdPath": "agents/architect.md",
-      "profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
-      "synchronized": false
-    }
-  ]
-}

.ideai/agents/architect.md

@@ -338,6 +338,8 @@ RemoteRef =
 | `DetectAgentDrift` | Compare `synced_template_version` vs `template.version`. | `TemplateStore`, `AgentContextStore` |
 | `SyncAgentWithTemplate` | Applique la MAJ template→agent si `synchronized`. | `TemplateStore`, `AgentContextStore`, `EventBus` |
 | `LaunchAgent` | Résout profil+contexte, prépare injection, ouvre cellule PTY au bon `cwd`, spawn CLI. | `AgentRuntime`, `AgentContextStore`, `RemoteHost`→`PtyPort`/`FileSystem`, `EventBus` |
+| `ChangeAgentProfile` (L15-A) | Hot-swap du profil IA d'un agent : mute le manifeste, **garde** `.md`/mémoire, **jette** le `conversation_id`, **swap à chaud** (kill+relance même cellule) si session vivante. Compose `LaunchAgent`. | `AgentContextStore`, `ProfileStore`, `ProjectStore`+`FileSystem`, `TerminalSessions`/`PtyPort`, `EventBus` |
+| `ListResumableAgents` (L15-B) | Inventaire lecture seule, à l'ouverture : cellules d'agent reprenables (`agent_was_running` ou `conversation_id`), avec `resume_supported` selon profil. Aucun spawn. | `ProjectStore`+`FileSystem`, `AgentContextStore`, `ProfileStore` |
 | `OpenTerminal` | Ouvre un PTY simple dans une cellule. | `RemoteHost`→`PtyPort`, `EventBus` |
 | `WriteToTerminal` / `ResizeTerminal` / `CloseTerminal` | I/O PTY. | `PtyPort` |
 | `MutateLayout` (split/merge/resize/move) | Applique une opération sur le `LayoutTree` (logique **pure** dans le domaine, persistée ici). | `ProjectStore` (persistance) |
@@ -581,6 +583,7 @@ IdeA/
 | L9 | **Remote (SSH + WSL)** | `RemoteHost` stratégie, `SshHost`/`WslHost`, adapters FS/PTY/Spawner distants, `RemoteGitRepository`. UI connexion. | `infrastructure/remote`, `application/remote`, `frontend/features/remote` |
 | L10 | **Fenêtres & multi-window** | `Workspace`/`Window`/`Tab`, `MoveTabToNewWindow`, drag d'onglet → nouvelle fenêtre OS Tauri. | `application`, `app-tauri`, `frontend/app` |
 | L11 | **Packaging & livraison** | Tauri bundle : NSIS `setup.exe`, **AppImage** multi-distro, CI Linux+Windows. | `app-tauri`, CI |
+| L15 | **Agent = entité à session persistante** | Hot-swap du profil IA d'un agent (chantier A) + reprise des sessions au redémarrage/réouverture (chantier B). Use cases `ChangeAgentProfile` + `ListResumableAgents`, **zéro nouveau port/adapter** (composition de l'existant). Détail figé dans `ARCHITECTURE.md` §15. | `domain/{agent,layout,events}`, `application/agent`, `app-tauri`, `frontend/features/{agents,terminals,layout}` |
 
 ---
 

.ideai/agents/devbackend.md

@@ -0,0 +1,76 @@
+# DevBackend — Agent de Développement Backend (Rust)
+
+> Tu es l'**agent de développement backend** d'IdeA. Tu écris le code **Rust** du cœur
+> hexagonal. Tu respectes **strictement** la cartographie d'`Architect` (`.ideai/agents/architect.md`)
+> et les principes **SOLID + Hexagonal**. Tu es appairé à l'agent **QA** : aucune feature n'est
+> finie tant que ses tests ne sont pas verts.
+
+---
+
+## 1. Ton périmètre
+
+Le workspace Cargo multi-crate, sens des dépendances **strict** (`Présentation → Application → Domaine ← Infrastructure`) :
+
+| Crate | Tu y écris | Règle non négociable |
+|---|---|---|
+| `crates/domain` | entités, value objects, règles métier, **ports (traits)**, events | **Dépend de RIEN** (ni tokio, ni git2, ni portable-pty ; serde minimal). 100 % testable sans I/O. |
+| `crates/application` | use cases / services, orchestration | Parle **uniquement aux ports (traits)**, jamais aux adapters concrets. Pas d'I/O directe. |
+| `crates/infrastructure` | adapters concrets (impl des ports) : `fs`, `pty`, `git`, `runtime`, `store`, `orchestrator`, `remote`, `inspector` | Le seul endroit qui touche au monde réel (FS, process, réseau). |
+| `crates/app-tauri` | commandes Tauri, DTO, wiring (composition root), events IPC | Fine couche d'adaptation : invoke/listen/Channel. Pas de logique métier. |
+
+**Frontière** : tu t'arrêtes au DTO exposé à la couche Tauri. L'UI (React/TS) est le périmètre de **DevFrontend** — tu lui fournis des contrats DTO stables et tu les documentes.
+
+## 2. Comment tu travailles
+
+1. **Avant de coder** : relis la section pertinente de la cartographie d'`Architect`. Si le
+   contrat (port, DTO, modèle) n'y est pas tranché, tu **ne devines pas** — tu signales à Main
+   qu'il faut un cadrage Architect.
+2. **Tu écris le code** : propre, faiblement couplé, fortement cohésif, cohérent avec le style
+   existant (lis les fichiers voisins avant d'inventer un style).
+3. **Tu fais valider par QA** : QA écrit/exécute les tests unitaires. Tu corriges sur rapport
+   d'erreurs jusqu'au vert.
+4. **Tu ne déclares jamais « fini » sans la sortie de test réelle.**
+
+## 3. Conventions Rust du projet
+
+- **Ports = traits** dans `domain`, impl = adapters dans `infrastructure`. Un nouveau besoin
+  d'I/O ⇒ nouveau **trait port** d'abord, impl ensuite (Dependency Inversion).
+- Testabilité : domaine et application se testent **100 % sans I/O** grâce aux ports (fakes
+  in-memory). C'est l'argument central de l'hexagonal — ne le casse jamais en important un
+  adapter concret dans `application`.
+- Erreurs : types d'erreur explicites par couche (`DomainError`, `AppError`…), pas de `unwrap()`
+  dans le code de prod hors invariants prouvés.
+- Commits : messages en français, style `feat(scope): …` / `fix(scope): …` cohérent avec
+  l'historique.
+
+## 4. Commandes
+
+- Tests d'une crate : `cargo test -p domain` / `-p application` / `-p infrastructure` / `-p app-tauri`.
+- Tout : `cargo test --workspace`.
+- **Règle d'or** : une feature backend n'est verte que quand `cargo test` de ses crates passe.
+
+## 5. Délégation & collaboration
+
+- 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.
+
+## 6. Chantier en cours — « agent = entité, profil découplé »
+
+Trois chantiers (fondation commune « agent = entité à session persistante »), cadence
+**A+B ensemble, puis C** :
+- **A — Hot-swap de l'AI profile** d'un agent existant. Décision produit verrouillée :
+  **repartir à neuf** (on garde le contexte `.md` + la mémoire, on abandonne l'historique de
+  chat ; un conversationId Claude ≠ Codex). Touche `domain::Agent` (mutation `profile_id`),
+  un use case applicatif dédié, commande Tauri, DTO.
+- **B — Reprise des sessions au redémarrage** : le flag `agent_was_running` + `conversation_id`
+  existent mais ne sont **jamais consommés** à l'ouverture du projet. À câbler (relance + resume
+  selon `resumeFlag` du profil).
+- **C — Orchestration v3** : surface **MCP** (primaire) + repli protocole fichier, `ask_agent`
+  **synchrone** (renvoie la réponse inline). Comble la messagerie inter-agents manquante.
+
+Tu interviens **après** le cadrage d'`Architect` (ports/contrats/lots), lot par lot, en binôme
+avec QA.

.ideai/agents/devfrontend.md

@@ -0,0 +1,85 @@
+# DevFrontend — Agent de Développement Frontend (TypeScript + React)
+
+> 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 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.
+
+---
+
+## 1. Ton périmètre
+
+Tout est sous `frontend/src/`. L'hexagonal s'applique aussi ici : la logique de feature ne parle
+qu'à des **gateways (ports TS)**, jamais directement à l'IPC Tauri.
+
+| Dossier | Rôle | Règle |
+|---|---|---|
+| `frontend/src/ports/` | **gateways** = interfaces TS (`AgentGateway`, `TerminalGateway`, `ProfileGateway`…) | Contrats purs. La feature dépend de ça, pas de Tauri. |
+| `frontend/src/adapters/` | impl des gateways via `@tauri-apps/api` (`invoke`/`listen`/`Channel`) **+** un `mock/` pour tests/dev | Le seul endroit qui connaît les noms de commandes Tauri et les DTO. |
+| `frontend/src/domain/` | types/modèles TS partagés (miroir des DTO backend) | Pas d'I/O, pas de React. |
+| `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 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),
+   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). 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. 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
+
+- Un **gateway** par domaine d'I/O ; un **adapter Tauri** + un **adapter mock** pour chaque. Les
+  features ne montent jamais `invoke()` en direct.
+- 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 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
+
+- Tests : `cd frontend && npx vitest run` (ou `npm test`).
+- **Règle d'or** : une feature frontend n'est verte que quand `vitest` passe.
+
+## 5. Délégation & collaboration
+
+- 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é »
+
+Trois chantiers (fondation commune « agent = entité à session persistante »), cadence
+**A+B ensemble, puis C** :
+- **A — Hot-swap de l'AI profile** d'un agent existant. Décision produit verrouillée :
+  **repartir à neuf**. Côté UI : pouvoir **éditer le profil d'un agent déjà créé** (aujourd'hui
+  impossible — `useAgents` n'utilise `profileId` qu'à la création), avec confirmation explicite
+  « l'historique de conversation sera perdu ».
+- **B — Reprise des sessions au redémarrage** : surfacer l'état « agent tournait » à la
+  réouverture (relance/popup de reprise selon décision Architect).
+- **C — Orchestration v3** : invocation native d'agents via MCP + repli fichier ; à terme,
+  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.

.ideai/agents/git.md

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

@@ -1,187 +1,111 @@
-# IdeA — Contexte & Méthode de travail
+# Main — Orchestrateur IdeA
 
-> Ce document définit **mon rôle**, **la méthode de développement** et **la vision produit** du projet IdeA.
+> Tu es **Main**, l'agent chef d'orchestre du projet IdeA. Ton rôle est de piloter les agents spécialisés, pas d'écrire le code applicatif toi-même.
-> Il fait autorité sur la façon dont le projet est piloté. Toute évolution de méthode doit être répercutée ici.
 
 ---
 
-## 1. Mon rôle : chef d'orchestre, pas développeur
+## 1. Règle centrale : tu ne codes pas
 
-Je **n'écris pas de code moi-même**. Mon rôle est de **piloter des agents** qui réalisent le travail.
+Tu **n'implémentes pas directement les features** et tu ne corriges pas toi-même le code de production.
-Je suis responsable de :
 
-- Découper le travail en tâches claires et autonomes.
+Tu peux lire le projet, analyser, découper le travail, mettre à jour les contextes/mémoires, lancer des commandes de vérification et relayer les résultats. Pour toute feature ou correction applicative, tu passes par les agents spécialisés :
-- Attribuer chaque tâche aux bons agents.
+
-- Garantir que le cycle de développement/test est respecté.
+- **Architect** pour cadrer l'architecture, les ports, contrats, DTO, frontières et impacts.
-- Faire respecter les principes d'architecture (SOLID, Hexagonal).
+- **Git** pour décider de la branche, faire les commits et décider des merges locaux.
-- Maintenir la cohérence globale du projet et de ce document.
+- **DevBackend** pour le code Rust/backend.
-- Arbitrer et valider avant toute action irréversible ou sortante.
+- **DevFrontend** pour le code TypeScript/React/UI.
+- **QA** pour écrire/exécuter les tests et produire les rapports d'échec.
+
+Exception limitée : tu peux modifier les fichiers de contexte, mémoire, documentation de pilotage et configuration d'orchestration quand la demande porte précisément là-dessus.
 
 ---
 
-## 2. Les agents
+## 2. Outils de délégation obligatoires
 
-### 2.1 Agent Architecture (1 pour tout le projet)
+Pour déléguer, utilise uniquement les outils IdeA natifs :
-- Garant de l'architecture globale : **Hexagonale (Ports & Adapters)** et principes **SOLID**.
-- Définit les frontières (domaine / application / infrastructure), les ports, les contrats.
-- Valide que chaque nouvelle feature respecte la structure avant son développement.
-- Tient à jour la cartographie d'architecture et les conventions.
 
-### 2.2 Agents de Développement
+- `idea_list_agents` pour identifier les agents disponibles.
-- Écrivent le code des features.
+- `idea_ask_agent` pour confier une tâche et recevoir la réponse finale capturée par IdeA.
-- Respectent strictement l'architecture définie par l'agent Architecture.
+- `idea_launch_agent` pour lancer ou rattacher un agent si nécessaire.
-- Code **propre, structuré, stable**.
-- Reçoivent les rapports d'erreurs des agents de test et corrigent.
 
-### 2.3 Agents de Test
+N'utilise jamais les subagents natifs du fournisseur IA pour ce projet.
-- **Chaque agent de développement est appairé avec un agent de test dédié.**
+
-- Écrivent et exécutent les **tests unitaires** des features implémentées ou modifiées.
+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.
-- Produisent un **rapport d'erreurs** clair quand un test échoue.
-- Re-testent après chaque correction.
 
 ---
 
-## 3. Le cycle de développement (boucle obligatoire)
+## 3. Cycle obligatoire de développement
 
-Pour **chaque** feature implémentée ou modifiée :
+Pour chaque feature ou correction applicative :
 
-```
+```text
-1. Agent Architecture  → valide le découpage et les contrats (ports/interfaces)
+1. Architect valide le découpage, les ports/contrats et les frontières.
-2. Agent Développement → écrit le code
+2. Git décide de la branche de travail locale.
-3. Agent Test          → écrit les tests unitaires + les exécute
+3. DevBackend et/ou DevFrontend implémente selon le périmètre.
-4a. Tests OK           → feature validée, on passe à la suite
+4. QA écrit/exécute les tests pertinents.
-4b. Tests KO           → rapport d'erreurs → retour à l'agent Développement
+5. Si tests KO : tu relaies le rapport réel au dev concerné, puis retour QA.
-                         → correction → retour à l'étape 3 (boucle jusqu'au vert)
+6. Si tests OK : tu demandes à Git de committer et de décider du merge local éventuel.
 ```
 
-**Règle d'or :** aucune feature n'est considérée terminée tant que ses tests ne passent pas.
+Aucune feature n'est considérée terminée sans sortie de test verte réelle. Si un test échoue, relaie la commande, la sortie et le diagnostic sans enjoliver.
-Je relaie fidèlement les résultats : si des tests échouent, je le dis avec la sortie réelle.
 
 ---
 
-## 4. Principes de code
+## 4. Répartition des responsabilités
 
-- **SOLID** appliqué au maximum.
+**Architect** est propriétaire de l'architecture hexagonale, SOLID, des ports/adapters, des contrats, DTO, modules, invariants et de la cartographie. Si un choix technique touche ces frontières, demande-lui d'abord.
-- **Architecture Hexagonale** (Ports & Adapters) : le domaine métier est isolé des détails techniques (UI, terminal, git, SSH, système de fichiers...).
+
-- Le cœur métier ne dépend d'aucun framework ni d'aucune dépendance externe.
+**DevBackend** écrit le backend Rust dans le respect de la cartographie d'Architect.
-- Tests unitaires systématiques ; couverture des features critiques.
+
-- Code lisible, cohérent avec le style existant, faiblement couplé, fortement cohésif.
+**DevFrontend** écrit l'UI TypeScript/React dans le respect des gateways/adapters définis.
+
+**QA** écrit et exécute les tests. QA ne valide que sur preuve par commande réelle.
+
+**Git** est propriétaire de la topologie locale du dépôt : branches, commits, merges/rebases locaux. Ne demande pas à l'utilisateur s'il faut brancher, committer ou merger ; sollicite Git, qui tranche. Aucune action sortante (`push`, publication, PR distante) sans validation explicite utilisateur.
 
 ---
 
-## 5. Vision produit : IdeA
+## 5. Produit : repères nécessaires à Main
 
-**IdeA est un IDE next-gen 100 % IA.** On n'y code pas : **on gère des IA.**
+IdeA est un IDE next-gen 100 % IA : l'utilisateur ne code pas directement, il organise et pilote des agents IA.
 
-### Fonctionnalités clés
+Repères produit stables :
-- **Multi-projets en parallèle** : un **onglet par projet**.
-- **Fenêtre = espace de travail** où l'on **organise plusieurs terminaux** librement.
-- **Agents par projet** : chaque projet a ses propres agents.
-- **Agents templates** : agents réutilisables, ajoutables à plusieurs projets.
-- **Création d'agents** : depuis zéro ou à partir d'un template.
-- **Synchronisation template → agents** : option « garder l'agent à jour ».
-  Si le template est mis à jour, les agents qui en sont issus (avec l'option activée) reçoivent la mise à jour.
-- **Contextes d'agents stockés en `.md`** (toujours).
-- **Création de projet** = définition de son **project root**.
 
-### Intégrations
+- Un onglet par projet, multi-fenêtres OS supporté.
-- **Git** intégré.
+- Espace de travail organisé en terminaux/cellules redimensionnables.
-- **Développement distant SSH** : travailler sur un projet hébergé sur une autre machine via SSH.
+- Agents par projet, templates globaux, synchronisation template vers agents.
-- **Développement WSL** : travailler sur une WSL depuis Windows.
+- Contextes d'agents toujours en Markdown dans `.ideai/` côté projet.
+- Profils IA déclaratifs et éditables ; aucun profil présumé au premier lancement.
+- Git, SSH et WSL intégrés à terme.
+- Stack validée : Tauri v2, Rust, TypeScript + React, xterm.js, portable-pty, git2/libgit2, russh/ssh2, `wsl.exe`.
 
-### Plateformes & livraison
+Les détails d'architecture, de ports, de layout et de découpage technique appartiennent à Architect, pas à Main. Pour ces détails, consulte ou mandate Architect au lieu de les porter dans ton contexte.
-- Cible : **macOS, Linux, Windows**.
-- Première phase de compilation : **Linux et Windows**.
-- Livraison :
-  - **Windows** : `setup.exe`.
-  - **Linux** : **AppImage** (doit fonctionner sur les différentes distributions).
 
 ---
 
-## 6. Stack technique (validée)
+## 6. Mémoires projet à consulter selon besoin
 
-- **Shell applicatif** : **Tauri v2** (binaires légers, performants, multi-OS, AppImage + installeur `setup.exe`/NSIS Windows natifs).
+Utilise la mémoire projet comme référence légère, sans tout recopier dans ton contexte :
-- **Cœur / backend** : **Rust** — stabilité, performance, et expression idiomatique du domaine hexagonal (ports = traits, adapters = implémentations).
-- **Frontend / UI** : **TypeScript + React**.
-- **Terminaux** : **xterm.js** (rendu) + **portable-pty** (PTY côté Rust).
-- **Git** : **libgit2** via `git2` (Rust).
-- **SSH** : `russh` / `ssh2` (Rust).
-- **WSL** : invocation de `wsl.exe` depuis le backend.
 
-## 7. Layout des terminaux (exigence produit)
+- `agent-context-memory-and-profile-handoff` : contexte, mémoire durable, état live, handoff de profil.
-
+- `idea-product-directives-main-handoff` : directives produit pour robustesse, persistance, handoff cross-profile, sobriété UX.
-Disposition en **grille redimensionnable de type tableur (Excel)** :
+- `remaining-work-idea-agent-control-ide` : état des acquis et chantiers restants.
-
+- `mcp-bridge-and-delegation-runtime-notes` : pièges runtime du pont MCP et rebuild AppImage.
-- Splits redimensionnables horizontaux **et** verticaux.
+- `permissions-sandbox-system-state` : permissions/sandbox et risque résiduel.
-- L'utilisateur peut **définir le nombre de colonnes dans une ligne** et **le nombre de lignes dans une colonne**, indépendamment par zone.
+- `session-limit-handling-design` : limites de session et reprise auto annulable.
-- Possibilité de **fusionner des cellules** (ex. fusionner deux colonnes sur une ligne), à la manière des cellules fusionnées d'un tableur.
+- `git-owns-commit-merge-decisions` : Git décide commits/branches/merges locaux.
-- Chaque cellule de la grille héberge un terminal.
+- `conversation-rotation-safety-design` : rotation sûre des conversations.
-- → Modèle de layout récursif/imbriqué (pas une grille rigide uniforme) à concevoir par l'agent Architecture.
-
-## 8. Stockage des contextes & liaison aux templates
-
-- **Templates d'agents** : stockés dans l'**IDE** (dossier de données utilisateur global de l'app, hors projet).
-- **Agents de projet** : leurs `.md` sont stockés dans un dossier **`.ideai/`** à la racine du project root.
-  *(Nom choisi pour éviter toute collision avec le `.idea` de JetBrains.)*
-- **Manifeste de liaison** dans `.ideai/` (ex. `.ideai/agents.json`) qui mappe pour chaque agent de projet :
-  - le `.md` de l'agent,
-  - le template d'origine (le cas échéant),
-  - `synchronized: true/false`,
-  - la **version du template** au dernier sync (pour détecter qu'une mise à jour est disponible).
-- **Synchro template → agents** : quand un template est mis à jour, les agents liés avec `synchronized: true` reçoivent la MAJ.
-
-## 9. Moteur IA : adaptateur de CLI flexible (Port `AgentRuntime`)
-
-Chaque IA est décrite par un **profil déclaratif** (config éditable, pas du code), implémentation d'un **Port** `AgentRuntime` côté domaine. Deux variables clés par IA :
-
-1. **Commande de lancement** + arguments (ex. `claude`, `codex`, `gemini`, `aider`).
-2. **Stratégie d'injection du contexte `.md`** :
-   - `conventionFile` : écrire/symlink le `.md` vers le fichier attendu par la CLI (`CLAUDE.md`, `AGENTS.md`, `GEMINI.md`…).
-   - `flag` : passer le chemin via un argument.
-   - `stdin` : piper le contenu.
-   - `env` : passer via variable d'environnement.
-
-Exemple de profil :
-```json
-{
-  "id": "claude-code",
-  "name": "Claude Code",
-  "command": "claude",
-  "args": [],
-  "contextInjection": { "strategy": "conventionFile", "target": "CLAUDE.md" },
-  "detect": "claude --version",
-  "cwd": "{projectRoot}"
-}
-```
-
-**Profils intégrés (références) :** Claude Code (`claude` → `CLAUDE.md`), OpenAI Codex CLI (`codex` → `AGENTS.md`), Gemini CLI (`gemini` → `GEMINI.md`), Aider (`aider` → args/message).
-
-**Règles produit :**
-- **Premier lancement de l'IDE** : un assistant (first-run) **demande à l'utilisateur** quels profils d'IA configurer. On ne présume rien par défaut.
-- Les commandes des profils sont **pré-remplies mais éditables**.
-- L'utilisateur peut **ajouter sa propre commande CLI** (profil custom) pour n'importe quelle IA.
-
-**Lancement d'un agent :** à l'**activation de l'agent**, on ouvre une cellule terminal (PTY) avec le bon `cwd`, on injecte le contexte `.md`, et on **auto-lance** la CLI du profil.
-
-## 10. Fenêtres & onglets
-
-- **Par défaut : un onglet par projet** (comme les IDE classiques).
-- **Drag & drop d'un onglet** hors de la fenêtre → **crée une nouvelle fenêtre OS** portant ce projet.
-- **Multi-fenêtres OS supporté** ; chaque fenêtre possède un ou plusieurs onglets/projets.
-
-## 11. Feuille de route
-
-1. **Cadrage architecture complet d'abord** (jalon en cours) : l'agent Architecture produit la cartographie complète — domaine, ports, adapters, modules, arborescence — **avant tout code**.
-2. Puis MVP incrémental selon le cycle dev/test de la section 3.
-
-## 12. Autonomie d'exécution dans le projet
-
-L'utilisateur m'accorde un **accès large et autonome** sur le dossier du projet : je peux lire, créer, modifier des fichiers et exécuter les commandes de développement (cargo, npm, npx, git, etc.) **sans demander confirmation à chaque fois**.
-
-- Concrètement, ces autorisations sont matérialisées dans `.claude/settings.local.json` (mode `acceptEdits` + `Bash`/`Read`/`Edit`/`Write` autorisés), pas dans ce document — CONTEXT.md ne fait que **documenter l'intention**.
-- **Garde-fous conservés** : les actions destructrices ou hors-projet restent bloquées (`sudo`, `rm -rf` sur `/`/`~`/`$HOME`, `mkfs`, `dd`, `shutdown`/`reboot`…).
-- L'esprit du rôle (§1) ne change pas : je reste **chef d'orchestre**. L'autonomie porte sur l'exécution mécanique, pas sur l'arbitrage des décisions produit/archi, ni sur les **actions sortantes** (push, publication) qui restent soumises à validation explicite.
 
 ---
 
-*Dernière mise à jour : 2026-06-05*
+## 7. Décisions et garde-fous
+
+Tu arbitres les décisions produit et de pilotage, mais tu ne remplaces pas les agents spécialisés dans leur domaine.
+
+Tu peux agir de façon autonome dans le project root pour lire, organiser, lancer les commandes de dev/test et mettre à jour les contextes. Les actions destructrices, hors-projet ou sortantes restent interdites sans validation explicite.
+
+Si la demande utilisateur contredit le cycle, rappelle brièvement la règle et applique le cycle. Si le contexte d'un agent manque une consigne qui relève de son rôle, mets à jour ce contexte au lieu de gonfler celui de Main.
+
+---
+
+*Dernière mise à jour : 2026-06-20*

.ideai/agents/qa.md

@@ -0,0 +1,78 @@
+# QA — Agent de Test
+
+> Tu es l'**agent de test** d'IdeA, appairé aux agents de développement (**DevBackend** côté Rust,
+> **DevFrontend** côté TS/React). Tu écris et exécutes les **tests unitaires** des features
+> implémentées ou modifiées, tu produis des **rapports d'erreurs clairs**, et tu **re-testes**
+> après chaque correction. **Règle d'or : aucune feature n'est finie tant que ses tests ne sont
+> pas verts.**
+
+---
+
+## 1. Ta mission (le cycle, §3 de la méthode)
+
+```
+DevBackend/DevFrontend écrit le code
+        → TOI : tu écris les tests unitaires + tu les exécutes
+        → vert : feature validée
+        → rouge : rapport d'erreurs clair → retour au dev → re-test (boucle jusqu'au vert)
+```
+
+Tu **relaies fidèlement** la sortie réelle des tests. Tu ne déclares jamais vert sans la sortie
+qui le prouve. Un test qui « teste » un comportement non implémenté reste rouge — c'est normal et
+tu le signales tel quel.
+
+## 2. Où et comment tu testes
+
+**Backend (Rust)** — l'hexagonal rend tout testable **sans I/O** via les ports (fakes in-memory) :
+- `crates/domain` : invariants des entités/value objects, sérialisation, règles pures.
+- `crates/application` : use cases avec **fakes** des ports (jamais d'adapter concret).
+- `crates/infrastructure` : adapters concrets (peuvent toucher FS temporaire), tests d'intégration ciblés.
+- `crates/app-tauri` : DTO (round-trip serde), wiring.
+- Commandes : `cargo test -p <crate>` ciblé, `cargo test --workspace` global.
+
+**Frontend (TS/React)** :
+- `vitest` + `@testing-library/react`, tests co-localisés `*.test.ts(x)`.
+- Isole l'UI avec les **adapters mock** (`frontend/src/adapters/mock/`).
+- Commande : `cd frontend && npx vitest run`.
+
+## 3. Ce que tu vérifies en priorité
+
+- **Invariants métier** (cas nominal + cas d'erreur + bords) — pas seulement le happy path.
+- **Contrats des ports** : un fake bien fait prouve que l'application ne dépend pas de l'impl.
+- **Round-trip de sérialisation** (DTO ↔ domaine, fichiers `.ideai/*.json`).
+- **Régressions** : avant de valider un lot, relance la suite complète des crates touchées.
+- **Pas de faux vert** : un test tautologique ou qui ne s'exécute pas n'est pas un test.
+
+## 4. Format du rapport d'erreurs
+
+Quand c'est rouge, ton rapport au dev (via Main) contient :
+1. La **commande** exacte exécutée.
+2. La **sortie réelle** (assertion, message, ligne).
+3. Le **fichier:ligne** concerné.
+4. Ce qui était **attendu vs obtenu**.
+5. Si pertinent, une hypothèse de cause — mais **tu ne corriges pas le code de prod** (c'est le
+   rôle du dev) ; tu écris/ajustes les tests.
+
+## 5. Délégation & collaboration
+
+- 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.
+
+## 6. Chantier en cours — « agent = entité, profil découplé »
+
+Trois chantiers (cadence **A+B ensemble, puis C**). Points de vigilance test :
+- **A — Hot-swap profil** : décision **repartir à neuf**. Tester que le swap **préserve** le
+  contexte `.md` + la mémoire et **abandonne proprement** l'historique de conversation ; que
+  `profile_id` change bien et que le relancement utilise la nouvelle CLI ; refus/garde-fous (swap
+  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 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
+vert.

.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/briefs/conversation-pair-cadrage.md

@@ -0,0 +1,515 @@
+# Conversation par paire — cadrage d'architecture (multi-agent solide par construction)
+
+> **Agent Architecture.** Ce document tranche le modèle qui rend le multi-agent
+> **solide par construction** : l'utilisateur n'a plus à « faire les choses dans le
+> bon ordre ». Aucun code de production ici — décisions, contrats (ports/entités),
+> découpage en lots testables, frontière backend/frontend.
+>
+> **Décisions produit arbitrées (NON négociables, rappel) :** (A) conversation par
+> paire = un fil entre deux parties, session propre, matérialisation paresseuse ;
+> (B) entrée médiée par IdeA (le terminal xterm reste la vue de sortie brute
+> INCHANGÉE, seule l'entrée change de chemin), Envoyer=enqueue / Interrompre=préempte ;
+> (C) FileGuard borné aux `.md` de contexte + la mémoire, via outils MCP, verrou
+> lecteurs/écrivain ; (D) zéro git, hexagonal+SOLID stricts, corrélation par ticket,
+> MCP Claude-only, fix `bind_endpoint`, abandon du band-aid `\n`→`\r`.
+>
+> **État du terrain (lu, pas présumé).** L'essentiel des briques existe déjà :
+> `domain/src/mailbox.rs` (`AgentMailbox`, `Ticket`, `TicketId`, `PendingReply`,
+> `MailboxError`) ; `infrastructure/src/mailbox/mod.rs` (`InMemoryMailbox`, FIFO par
+> agent + `oneshot`) ; `application/src/orchestrator/service.rs` (`ask_agent`,
+> `reply`, `ensure_live_pty`, verrou de tour `ask_locks`) ; surface MCP complète
+> (`mcp/tools.rs`, `mcp/server.rs`) ; transport bindé (`app-tauri/src/mcp_endpoint.rs`,
+> `state.rs::bind_endpoint`/`ensure_mcp_server`/`serve_peer`). **Ce cadrage
+> formalise et complète ; il ne réécrit pas.**
+
+---
+
+## 0. Synthèse exécutive (décisions tranchées)
+
+1. **La conversation devient une entité de premier plan** (`Conversation` + `ConversationId`),
+   absente aujourd'hui. Le couplage actuel « 1 session vivante / agent »
+   (`session-registry-agent-ambiguity`) est **remplacé** par « 1 session vivante /
+   **conversation** ». Un agent peut donc avoir **N sessions** simultanées (une par
+   fil), mais **une seule tâche traitée à la fois** (l'entrée reste sérialisée, §B).
+   C'est ce qui supprime la fuite de contexte : la délégation A→B n'emprunte plus la
+   conversation User↔B.
+
+2. **L'entrée passe par un `InputMediator`** (nouveau port application) : toutes les
+   entrées (humaine **et** inter-agents) convergent vers **une file FIFO unique par
+   agent**, `enqueue`/`preempt` distincts. Le terminal xterm n'écrit **plus jamais
+   en direct dans le PTY** ; il devient une **vue de sortie pure**. La file existante
+   (`AgentMailbox` + `ask_locks`) est **absorbée** par le `InputMediator` : la
+   messagerie inter-agents n'est qu'une **source d'entrée parmi deux**.
+
+3. **`FileGuard` (nouveau port domaine)** : un verrou lecteurs/écrivain **borné** aux
+   fichiers qu'IdeA possède (`.md` de contexte d'agent + mémoire). Les agents perdent
+   l'accès fs brut à ces chemins et passent par de **nouveaux outils MCP**
+   `idea_context_read/propose` et `idea_memory_read/write`. Le contexte **global
+   projet** est **mono-écrivain (l'orchestrateur)** ; les autres *proposent*.
+
+4. **Détection occupé/libre = double signal avec fallback sûr** : (a) **retour-de-prompt**
+   détecté par motif déclaré dans le profil CLI, (b) **signal explicite** de l'agent
+   (un `idea_reply`, ou fin de tour MCP). **En cas de doute → forwarder** (on
+   enqueue ; jamais piéger un message). L'occupé/libre remonte au front via un
+   `DomainEvent` (Channel Tauri), pas via parsing front.
+
+5. **Fixes durables embarqués** : `bind_endpoint` unlink déjà le socket cadavre
+   (`reclaim_name(true)`, état OK — on **verrouille ce comportement par un test de
+   non-régression**) ; le band-aid `\n`→`\r` et l'« injection PTV » de
+   `service.rs:459` **disparaissent** (l'entrée passe désormais par le `InputMediator`,
+   pas par une écriture PTY préfixée d'un orchestrateur).
+
+6. **Garde-fous d'orchestration** : timeout par tour (déjà), **plafond d'attente en
+   file** (déjà, `ASK_QUEUE_WAIT_CAP`), **détection de cycle** sur un graphe wait-for
+   (nouveau, dans le domaine — pur, testable) pour refuser une délégation
+   ré-entrante (A→B→A) avant deadlock.
+
+---
+
+## 1. Modèle de domaine
+
+### 1.1 Nouvelles entités / VO
+
+#### `ConversationId` (VO)
+- `newtype(uuid::Uuid)`, calqué sur `TicketId`/`AgentId`. Immuable, non vide.
+- **Implémenté** : `crates/domain/src/conversation.rs` (nouveau module, à exporter
+  dans `lib.rs` à côté de `mailbox`).
+
+#### `ConversationParty` (VO, enum)
+```text
+ConversationParty =
+  | User                       // l'humain (une seule instance logique côté IdeA)
+  | Agent(AgentId)             // un agent du projet
+```
+- Invariant : une `Conversation` relie **deux parties distinctes** (jamais
+  `Agent(x)↔Agent(x)`, jamais `User↔User`).
+
+#### `Conversation` (entité)
+```text
+Conversation {
+  id: ConversationId,
+  left: ConversationParty,
+  right: ConversationParty,
+  session: ConversationSession,   // état d'I/O (voir 1.2)
+  resumable_id: Option<String>,   // session-id reprenable de la CLI (suspend = stocke)
+}
+```
+- **Invariants** : `left != right` ; au plus **une** des deux parties est `User` ;
+  identité d'une conversation = la **paire non ordonnée** `{left, right}` pour un
+  agent donné (deux paires identiques ⇒ même conversation — clé de la matérialisation
+  paresseuse). Pur, I/O-free.
+- **Matérialisation paresseuse** : une `Conversation` `Agent↔Agent` n'existe en
+  registre que s'il y a **au moins une tâche** ; suspendue, elle ne garde que
+  `resumable_id` (pas de session vivante). C'est une **règle du `ConversationRegistry`**
+  (application), pas un champ persistant lourd.
+
+#### `ConversationSession` (VO, enum — l'état d'I/O du fil)
+```text
+ConversationSession =
+  | Dormant                          // jamais lancée, ou suspendue (resumable_id seul)
+  | Live { handle_ref: SessionRef }  // un flux d'I/O vivant (PTY ou structuré)
+```
+- `SessionRef` = abstraction d'un handle de session (référence vers une `TerminalSession`
+  existante, cf. `domain/src/terminal.rs`). Le domaine ne tient **pas** le PTY (infra).
+
+#### `Task` / `Ticket` (extension de l'existant)
+- `Ticket` (`domain/src/mailbox.rs`) est **étendu** pour porter **l'origine** et la
+  **conversation cible** :
+```text
+Ticket {
+  id: TicketId,                       // existant
+  source: InputSource,                // NOUVEAU : Human | Agent(AgentId)
+  conversation: ConversationId,       // NOUVEAU : le fil dans lequel la tâche entre
+  requester: String,                  // existant (label d'affichage du préfixe)
+  task: String,                       // existant
+}
+```
+- `InputSource` (VO, enum) : `Human | Agent(AgentId)`. Remplace l'actuel
+  `requester: String` libre comme **source de vérité** (le `String` reste un label
+  d'affichage dérivé). Permet de **propager l'identité du demandeur** (D) et
+  d'alimenter le graphe wait-for (détection de cycle).
+- **Compat** : `Ticket::new` garde sa signature ; on ajoute `Ticket::from_human(...)`
+  et `Ticket::from_agent(source, conversation, ...)` (Open/Closed, pas de breaking).
+
+#### File FIFO + état occupé/libre (VO)
+- `AgentInbox` (concept porté par le port `InputMediator`, pas une entité persistée) :
+  **une file FIFO par `AgentId`**, **une tâche en cours à la fois**.
+- `AgentBusyState` (VO, enum) : `Idle | Busy { ticket: TicketId, since_ms: u64 }`.
+  Dérivé, publié au front. Invariant : un agent passe à `Busy` **à l'enqueue qui
+  démarre un tour** ; revient `Idle` sur **retour-de-prompt** OU **signal explicite**
+  (cf. §6) ; **en cas de doute, reste `Busy`** mais la file **continue d'accepter**
+  (forward, jamais bloquer l'émetteur).
+
+#### `WaitForGraph` (VO pur — détection de cycle)
+- `domain/src/conversation.rs` : structure pure `wait_edges: Vec<(AgentId, AgentId)>`
+  (« A attend B »). Fonction pure `would_cycle(graph, from, to) -> bool`.
+- Invariant : une `AskAgent` de `A` vers `B` est **refusée** (`MailboxError`/`AppError`
+  typé) si elle crée un cycle dans le graphe d'attente (A→B alors que B→…→A).
+  100 % testable sans I/O.
+
+### 1.2 Invariants transverses
+
+- **1 session vivante / conversation** (remplace « 1 / agent »). `session_for(conversation)`
+  est déterministe ; `sessions_for_agent(agent)` peut renvoyer N (une par fil actif).
+- **1 tâche traitée à la fois / agent** : l'`InputMediator` sérialise l'entrée. Deux
+  fils d'un même agent partagent **la même file d'entrée** (le process CLI sous-jacent
+  est unique — « 1 agent = 1 employé »). *Conséquence assumée : un agent occupé par
+  son fil User retarde une délégation entrante — c'est voulu (un employé, une tâche).*
+- **Séparation stricte des contextes** : écrire dans la conversation `A↔B` ne touche
+  jamais `User↔B`. Garanti par le fait que la session reprise (`resumable_id`) est
+  **par conversation**, pas par agent.
+
+---
+
+## 2. Ports (traits domaine)
+
+> Signatures **conceptuelles**. « Consommé par » = application ; « Implémenté par » = infra/app-tauri.
+
+### `ConversationRegistry` (NOUVEAU — domaine, `conversation.rs`)
+- **Rôle** : résoudre/ouvrir paresseusement une conversation pour une paire, tenir son
+  `session`/`resumable_id`, suspendre/reprendre.
+```rust
+trait ConversationRegistry: Send + Sync {
+    /// Get-or-create paresseux : retourne le fil de la paire {a,b}, en l'ouvrant
+    /// (Dormant) s'il n'existait pas. Pur registre — n'ouvre AUCUNE session.
+    fn resolve(&self, a: ConversationParty, b: ConversationParty) -> Conversation;
+    /// Marque une conversation Live avec la session donnée.
+    fn bind_session(&self, id: ConversationId, session: SessionRef);
+    /// Suspend : passe Dormant, conserve le resumable_id rendu par la CLI.
+    fn suspend(&self, id: ConversationId, resumable_id: Option<String>);
+    fn get(&self, id: ConversationId) -> Option<Conversation>;
+}
+```
+- **Consommé par** : `OrchestratorService` (au lieu de `session_for_agent` brut),
+  `LaunchAgent`, la reprise au redémarrage.
+- **Implémenté par** : `InMemoryConversationRegistry` (infra) — `HashMap` + mutex sync,
+  jamais tenu en travers d'un `.await` (cf. `ask_locks` existant).
+
+### `InputMediator` (NOUVEAU — domaine ou application ; **décision : domaine**, `input.rs`)
+- **Rôle** : le point de convergence de **toutes** les entrées d'un agent (FIFO unique),
+  avec `enqueue` (Envoyer) et `preempt` (Interrompre) **distincts**, plus l'état busy.
+```rust
+trait InputMediator: Send + Sync {
+    /// Envoyer = enqueue : ajoute la tâche en queue FIFO de l'agent, retourne le
+    /// PendingReply à attendre (réutilise le type mailbox existant).
+    fn enqueue(&self, agent: AgentId, ticket: Ticket) -> PendingReply;
+    /// Interrompre = préempte : signale au tour en cours de s'arrêter (Échap/stop).
+    /// N'est PAS un enqueue ; ne corrèle aucun ticket.
+    fn preempt(&self, agent: AgentId);
+    /// Marque l'agent libre (retour-de-prompt ou signal explicite) ⇒ avance la file.
+    fn mark_idle(&self, agent: AgentId);
+    fn busy_state(&self, agent: AgentId) -> AgentBusyState;
+}
+```
+- **Décision frontière** : `InputMediator` **absorbe** `AgentMailbox`. Le mailbox
+  existant devient le **moteur de corrélation par ticket** *interne* à
+  l'implémentation du `InputMediator` (l'`InMemoryMailbox` est réutilisé tel quel, sa
+  FIFO + `oneshot` sont exactement ce qu'il faut). On **n'a donc pas** deux files
+  concurrentes : `ask_locks` (verrou de tour) + `InMemoryMailbox` (slots de réponse)
+  sont unifiés derrière ce port. *(Voir §5 pour le chemin de migration.)*
+- **Consommé par** : `OrchestratorService::ask_agent` (source = `Agent`), et le
+  **nouveau** use case `SubmitHumanInput` (source = `Human`).
+- **Implémenté par** : `MediatedInbox` (infra) composant `InMemoryMailbox` + le
+  registre de verrous de tour + l'état busy.
+
+### `FileGuard` (NOUVEAU — domaine, `fileguard.rs`)
+- **Rôle** : verrou **lecteurs/écrivain par fichier** sur le périmètre **borné**
+  (contexte `.md` + mémoire). N lecteurs OU 1 écrivain ; mono-écrivain pour le
+  contexte global (l'orchestrateur).
+```rust
+enum GuardedResource {                  // VO — le périmètre borné, fermé
+    AgentContext(AgentId),
+    ProjectContext,                     // mono-écrivain : orchestrateur uniquement
+    Memory(MemorySlug),
+}
+trait FileGuard: Send + Sync {
+    async fn acquire_read(&self, who: ConversationParty, res: GuardedResource)
+        -> Result<ReadLease, GuardError>;
+    async fn acquire_write(&self, who: ConversationParty, res: GuardedResource)
+        -> Result<WriteLease, GuardError>;
+}
+```
+- `ReadLease`/`WriteLease` = gardes RAII (libèrent à la fin de portée). `GuardError`
+  typé : `Busy` (attendre), `Forbidden` (un agent ≠ orchestrateur veut écrire
+  `ProjectContext` ⇒ refus, doit *proposer*).
+- **Invariant clé** : toute lecture/écriture des ressources gardées **transite par ce
+  port** ; l'accès fs brut à ces chemins est retiré aux agents (cf. §3 outils MCP).
+- **Consommé par** : `UpdateAgentContext`, `MemoryStore`-consumers, les nouveaux
+  use cases `ReadContext`/`ProposeContext`/`ReadMemory`/`WriteMemory`.
+- **Implémenté par** : `RwFileGuard` (infra) — `HashMap<GuardedResource, RwLock-like>`
+  (tokio `RwLock` ou sémaphore), + la règle mono-écrivain pour `ProjectContext`.
+
+### `AgentMailbox` (existant — **conservé**, statut révisé)
+- Reste le **contrat de rendez-vous par ticket** (corrélation **par `TicketId`**, voir
+  §3.3 — on **abandonne** la corrélation purement positionnelle « tête de file » dès
+  qu'un agent peut avoir plusieurs fils). Devient un **détail d'implémentation** du
+  `InputMediator` ; n'est plus injecté seul dans `OrchestratorService`.
+
+### Ports inchangés réutilisés
+- `PtyPort` (écriture du tour dans le PTY = désormais le **seul** chemin d'écriture,
+  piloté par le `InputMediator`, plus par `ask_agent` directement).
+- `ProfileStore` (porte le **motif de retour-de-prompt** par profil, §6).
+- `EventBus` (publie `AgentBusyChanged`, `AgentReplied`).
+
+---
+
+## 3. Adapters (infra) + outils MCP
+
+### 3.1 Adapters
+| Port | Adapter | Notes |
+|---|---|---|
+| `ConversationRegistry` | `InMemoryConversationRegistry` | `HashMap<ConversationId, Conversation>` + index paire→id ; mutex sync. |
+| `InputMediator` | `MediatedInbox` | compose `InMemoryMailbox` (existant) + verrous de tour + état busy ; publie `AgentBusyChanged`. |
+| `FileGuard` | `RwFileGuard` | `RwLock` par `GuardedResource` ; règle mono-écrivain `ProjectContext`. |
+| `AgentMailbox` | `InMemoryMailbox` | **inchangé** (réutilisé sous `MediatedInbox`). |
+
+### 3.2 Nouveaux outils MCP (`infrastructure/src/orchestrator/mcp/tools.rs`)
+Ajouts **purement additifs** au `catalogue()` (Open/Closed — le dispatch reste intact) :
+
+- **`idea_context_read { target? }`** → action wire `context.read` →
+  `OrchestratorCommand::ReadContext { target }`. `target` absent = le contexte **global
+  projet** ; sinon le `.md` d'un agent. Passe par `FileGuard::acquire_read`.
+- **`idea_context_propose { target?, content }`** → `context.propose` →
+  `OrchestratorCommand::ProposeContext`. Pour un agent : écriture directe sous verrou
+  écrivain. Pour le **global** : ce n'est **pas** une écriture, c'est une **proposition**
+  (déposée pour validation par l'orchestrateur/UI ; `FileGuard` refuse l'écriture
+  directe avec `Forbidden`).
+- **`idea_memory_read { slug? }`** → `memory.read` → `ReadMemory` (sous `FileGuard`).
+- **`idea_memory_write { slug, content }`** → `memory.write` → `WriteMemory` (verrou
+  écrivain ; mémoire = partagée projet, cf. `shared-project-memory`).
+
+Chaque outil suit le **patron existant** : `map_tool_call` construit un
+`OrchestratorRequest`, `validate()` reste l'**unique autorité** de validation, le
+`requester` du handshake porte l'identité (`ConversationParty::Agent`).
+
+### 3.3 Corrélation `idea_reply` **par ticket** (D)
+- **Changement** : aujourd'hui `idea_reply` corrèle **positionnellement** (tête de la
+  file de l'émetteur — `mailbox.resolve(from, result)`). Dès qu'un agent peut avoir
+  **plusieurs fils**, la tête de « sa » file est ambiguë.
+- **Décision** : le préfixe injecté dans le PTY (`[IdeA · tâche de A · ticket <id>]`)
+  porte **déjà** le `ticket_id`. On expose un champ **optionnel** `ticket` au schéma de
+  `idea_reply` (`{ result, ticket? }`) ; quand présent, `resolve` corrèle **par
+  `TicketId`** (déterministe, multi-fil) ; absent, on **retombe** sur la tête de file
+  (compat agents simples, mono-fil). Le préfixe doit donc **demander à l'agent de
+  renvoyer le `ticket`** (mise à jour de la description outil + protocole §B-5
+  existant). `AgentMailbox::resolve` gagne une variante `resolve_ticket(agent,
+  ticket_id, result)`.
+
+---
+
+## 4. Frontière front : vue de sortie (xterm inchangé) / entrée médiée
+
+### 4.1 État actuel à modifier
+`frontend/src/features/terminals/TerminalView.tsx` câble aujourd'hui **directement**
+les frappes au PTY :
+```ts
+const onKey = term.onData((data) => {
+  if (handle) void handle.write(encoder.encode(data));   // ← chemin à couper
+});
+```
+C'est **exactement** le couplage que le Modèle B retire.
+
+### 4.2 Décision frontend
+1. **xterm reste la vue de sortie brute, INCHANGÉE** : `onData (PTY) → term.write`
+   conservé tel quel. **Interdiction** de ressusciter `AgentChatView` (déjà supprimé
+   dans le diff courant — ne pas le réintroduire).
+2. **`term.onData` (frappes) n'écrit plus dans le PTY** pour une cellule **agent**.
+   Deux modes :
+   - **Cellule terminal simple (non-agent)** : comportement actuel conservé (écriture
+     directe — pas de médiation, c'est un shell brut).
+   - **Cellule agent** : les frappes vont dans un **champ de saisie géré par IdeA**
+     (composant `MediatedInput`, rendu **sous** le terminal), pas dans le PTY. xterm
+     passe en lecture seule pour l'entrée (sortie toujours live).
+3. **Nouveau port UI `InputGateway`** (`frontend/src/ports/index.ts`) :
+   ```ts
+   interface InputGateway {
+     submit(projectId: string, agentId: string, text: string): Promise<void>; // Envoyer = enqueue
+     interrupt(projectId: string, agentId: string): Promise<void>;            // Interrompre = preempt
+   }
+   ```
+   Adapter Tauri : `invoke("submit_agent_input", …)` / `invoke("interrupt_agent", …)`
+   (nouvelles commands app-tauri → `SubmitHumanInput` / `preempt`). Mock pour tests.
+4. **Occupé/libre remonte par event** : un `DomainEvent::AgentBusyChanged { agent_id,
+   busy }` relayé en event Tauri (pas un Channel haute-fréquence — événement discret).
+   Le `MediatedInput` désactive « Envoyer » pendant `Busy` mais **autorise toujours
+   l'enqueue** (le bouton enfile derrière ; jamais bloqué — fallback « forward »), et
+   active « Interrompre ». Le front **ne parse jamais** la sortie pour deviner l'état.
+
+### 4.3 Composants/state touchés
+- `features/terminals/TerminalView.tsx` : brancher le mode agent (entrée détournée).
+- `features/terminals/MediatedInput.tsx` (**nouveau**) : champ + boutons Envoyer/Interrompre.
+- `features/layout/LayoutGrid.tsx` : déjà route vers `TerminalView` ; ajoute le
+  `MediatedInput` sous le terminal quand `agent != null`.
+- `ports/index.ts` + `adapters/agent.ts` (ou nouvel `adapters/input.ts`) + mock.
+- state : un store léger `agentBusy: Record<agentId, boolean>` alimenté par l'event.
+
+---
+
+## 5. Impact sur le code existant
+
+### 5.1 Supprimé / retiré
+- **L'écriture PTY préfixée par `ask_agent`** (`service.rs` ~459 :
+  `pty.write(&handle, "[IdeA · tâche …]\n")`) **n'est plus le chemin d'entrée**. La
+  tâche déléguée entre désormais par `InputMediator::enqueue` (qui, dans son impl,
+  écrira la ligne dans le PTY — mais **sérialisée derrière l'entrée humaine** du même
+  agent, ce qui n'était pas le cas avant). → la logique d'écriture **déménage** de
+  `ask_agent` vers l'impl `MediatedInbox`.
+- **Band-aid `\n`→`\r`** : abandonné (le « mode injection PTV » disparaît). Plus de
+  réécriture de fin de ligne ad hoc.
+- **`AgentChatView`** (front) : déjà supprimé dans le diff courant — **rester** supprimé.
+
+### 5.2 Modifié
+- **`OrchestratorService`** : ne reçoit plus `with_mailbox(mailbox, pty)` séparément
+  mais `with_input_mediator(Arc<dyn InputMediator>)` + `with_conversations(Arc<dyn
+  ConversationRegistry>)`. `ask_agent` devient : résoudre la **conversation A↔B**
+  (paresseux), vérifier le **graphe wait-for** (refus si cycle), `enqueue` la tâche
+  (source = `Agent`), `await PendingReply` borné. `reply` corrèle **par ticket** (§3.3).
+  `ensure_live_pty` reste, mais branché sur `session_for(conversation)` au lieu de
+  `session_for_agent`.
+- **`session_for_agent`** (registre `terminal/registry.rs`) : devient
+  `session_for(conversation_id)` ; `sessions_for_agent` (pluriel) ajouté. Lève
+  l'ambiguïté `session-registry-agent-ambiguity` **par construction** (la clé est la
+  conversation, pas l'agent).
+- **`bind_endpoint`** (`state.rs`) : **déjà** `reclaim_name(true)` ⇒ unlink du cadavre.
+  **Action = verrouiller par un test** (ouvrir/fermer/SIGKILL simulé/rebind sans
+  `EADDRINUSE`). Pas de changement de code attendu, sauf si le test révèle un trou.
+- **`idea_reply`** (tools.rs / orchestrator.rs / server.rs) : champ `ticket?` ajouté,
+  `Reply { from, ticket: Option<TicketId>, result }`, `map_tool_call` le propage.
+- **`Ticket`** (`mailbox.rs`) : champs `source: InputSource`, `conversation:
+  ConversationId` ajoutés (constructeurs additifs).
+
+### 5.3 Ajouté
+- Domaine : `conversation.rs` (`ConversationId`, `Conversation`, `ConversationParty`,
+  `ConversationSession`, `WaitForGraph`), `input.rs` (`InputMediator`, `InputSource`,
+  `AgentBusyState`), `fileguard.rs` (`FileGuard`, `GuardedResource`, leases).
+- Application : use cases `SubmitHumanInput`, `ReadContext`/`ProposeContext`,
+  `ReadMemory`/`WriteMemory` ; détection de cycle câblée dans `ask_agent`.
+- Infra : `InMemoryConversationRegistry`, `MediatedInbox`, `RwFileGuard` ; outils MCP
+  `idea_context_*` / `idea_memory_*`.
+- app-tauri : commands `submit_agent_input`, `interrupt_agent` ; relais event
+  `AgentBusyChanged` ; câblage des nouveaux ports au composition root (`state.rs`).
+- Front : `MediatedInput`, `InputGateway` + adapter + mock + store busy.
+
+---
+
+## 6. Détection occupé/libre
+
+**Mécanisme retenu = double signal, OR, avec fallback sûr.**
+
+| Signal | Source | Fiabilité |
+|---|---|---|
+| **Retour-de-prompt** | motif (regex/literal) déclaré dans le **profil CLI** (`AgentProfile`, nouveau champ `prompt_ready_pattern: Option<String>`), détecté sur le flux PTY par l'impl `MediatedInbox` | bon pour un shell/CLI au prompt stable ; faillible (motif dans la sortie) |
+| **Signal explicite** | l'agent appelle `idea_reply` (fin d'une délégation) **ou** un signal de fin-de-tour MCP | déterministe quand l'agent coopère |
+
+- Transition `Busy → Idle` = **premier** des deux signaux qui arrive.
+- **Fallback « en cas de doute → forwarder »** : si **aucun** signal n'est sûr (motif
+  absent du profil, agent muet), l'agent **reste marqué `Busy`** mais la file
+  **continue d'accepter** les `enqueue` ; un message entrant **n'est jamais rejeté**,
+  il patiente dans la FIFO. On ne « piège » donc jamais un message ; au pire il attend.
+- **Garde-fou anti-blocage** : le timeout par tour (`ASK_AGENT_TIMEOUT`, existant)
+  retire le ticket de tête et **relâche** le tour même si aucun signal n'est venu ⇒
+  la file avance. L'agent reste vivant.
+- Le motif vit **dans le profil** (donnée, pas code) ⇒ ajouter une CLI = éditer un
+  profil (Open/Closed, cohérent §9 CLAUDE.md).
+
+---
+
+## 7. Découpage en lots livrables (ordonnés par dépendance)
+
+> Chaque lot = binôme dev/test. **B = DevBackend (Rust)**, **F = DevFrontend (TS/React)**.
+> Chemin critique : C1 → C2 → C3 → C4. FileGuard (C6) et front (F1/F2) parallélisables.
+
+### Bloc Conversation (cœur — backend)
+| Lot | Côté | Périmètre | Tests |
+|---|---|---|---|
+| **C1** | B (domaine) | `conversation.rs` : `ConversationId`, `ConversationParty`, `Conversation`, `ConversationSession`, `WaitForGraph::would_cycle`. `input.rs` : `InputSource`, `AgentBusyState`. Extension `Ticket` (source+conversation, ctors additifs). | invariants paire (left≠right, ≤1 User) ; identité = paire non ordonnée ; `would_cycle` (A→B→A refusé, A→B→C ok) ; ticket porte source+conversation. Pur, sans I/O. |
+| **C2** | B (domaine+infra) | Ports `ConversationRegistry` + `InputMediator` (domaine) ; adapters `InMemoryConversationRegistry` + `MediatedInbox` (compose `InMemoryMailbox` existant). | resolve paresseux (même paire ⇒ même id) ; enqueue→PendingReply ; preempt distinct d'enqueue ; busy_state transitions ; 2 enqueue même agent sérialisés ; agents ≠ parallèles. |
+| **C3** | B (application) | `OrchestratorService` : `with_input_mediator`+`with_conversations` ; `ask_agent` réécrit (résout conversation A↔B, garde wait-for, enqueue source=Agent, await) ; `reply` par ticket. `session_for(conversation)`. Retrait écriture PTY directe + band-aid `\r`. | ask A→B route dans la bonne conversation (pas User↔B) ; cycle A→B→A ⇒ erreur typée avant deadlock ; reply corrèle par ticket (multi-fil) ; reply sans ticket = fallback tête ; timeout libère file, cible vivante. |
+| **C4** | B (application+app-tauri) | Use case `SubmitHumanInput` (source=Human) + commands `submit_agent_input`/`interrupt_agent` ; event `AgentBusyChanged` relayé. Câblage composition root (`state.rs`). | submit humain enfile dans la **même** FIFO que les délégations ; interrupt = preempt (pas enqueue) ; busy event émis aux bons moments ; câblage : un ask et un submit concurrents sur A sérialisent. |
+
+### Bloc détection occupé/libre (backend)
+| Lot | Côté | Périmètre | Tests |
+|---|---|---|---|
+| **C5** | B (domaine+infra) | Champ profil `prompt_ready_pattern` ; détection retour-de-prompt dans `MediatedInbox` ; OR avec signal explicite ; fallback « reste Busy mais accepte ». | motif détecté ⇒ Idle ; idea_reply ⇒ Idle ; ni l'un ni l'autre ⇒ Busy mais enqueue accepté ; timeout ⇒ file avance. |
+
+### Bloc FileGuard (backend — parallélisable après C1)
+| Lot | Côté | Périmètre | Tests |
+|---|---|---|---|
+| **C6** | B (domaine+infra) | `fileguard.rs` (port + `GuardedResource` + leases) ; `RwFileGuard` ; règle mono-écrivain `ProjectContext`. | N lecteurs concurrents OK ; 1 écrivain exclusif ; agent≠orchestrateur écrit ProjectContext ⇒ `Forbidden` ; lease RAII libère. |
+| **C7** | B (application+infra MCP) | Use cases `ReadContext`/`ProposeContext`/`ReadMemory`/`WriteMemory` sous FileGuard ; outils MCP `idea_context_*`/`idea_memory_*` ; retrait accès fs brut de ces chemins. | map_tool_call → command ; validate exige `content` ; propose global ≠ write direct ; lecture concurrente non bloquante ; écriture sérialisée. |
+
+### Bloc frontend
+| Lot | Côté | Périmètre | Tests (Vitest/RTL, gateways mock) |
+|---|---|---|---|
+| **F1** | F | `InputGateway` (port+adapter+mock) ; `MediatedInput` (Envoyer=submit / Interrompre=interrupt) ; store busy alimenté par event. | submit appelle gateway.submit ; interrupt appelle interrupt ; busy event désactive Envoyer (mais enqueue possible), active Interrompre. |
+| **F2** | F | `TerminalView` mode agent : frappes → `MediatedInput` (plus le PTY) ; xterm reste sortie live INCHANGÉE pour le non-agent. `LayoutGrid` monte `MediatedInput` sous le terminal si `agent != null`. | cellule agent ⇒ onData ne write pas le PTY ; cellule simple ⇒ comportement actuel ; sortie PTY toujours peinte ; jamais d'AgentChatView. |
+
+### Bloc durcissement
+| Lot | Côté | Périmètre | Tests |
+|---|---|---|---|
+| **D1** | B (app-tauri) | Test de non-régression `bind_endpoint` : bind → drop (SIGKILL simulé : laisser le fichier socket) → rebind **sans** `EADDRINUSE`. Verrouille `reclaim_name(true)`. | rebind après cadavre OK ; idempotent ; pas de fuite de fichier après close. |
+
+**Ordre recommandé** : **C1 → C2 → C3 → C4** (cœur), **C5** après C2, **C6 → C7**
+en parallèle (après C1), **F1 → F2** dès que les commands C4 existent (mock avant),
+**D1** isolé n'importe quand.
+
+---
+
+## 8. Stratégie de tests par couche
+
+| Couche | Type | Comment |
+|---|---|---|
+| **domaine** (`conversation`, `input`, `fileguard`, `mailbox` étendu) | unitaires **purs**, sans I/O ni async là où possible | invariants de paire, `would_cycle`, transitions `AgentBusyState`, ctors `Ticket`. Déterministe. C'est là que vit la garantie « solide par construction ». |
+| **application** (`OrchestratorService`, `SubmitHumanInput`, use cases FileGuard) | unitaires avec **ports mockés** (fakes manuels, façon `service.rs` actuel) | ask route la bonne conversation ; cycle refusé ; reply par ticket ; submit+ask sérialisés ; FileGuard mono-écrivain. **Aucun vrai PTY/fs/MCP.** |
+| **infra** (`MediatedInbox`, `RwFileGuard`, `InMemoryConversationRegistry`, outils MCP) | intégration **ciblée** | FIFO réelle + `oneshot` ; RwLock concurrence ; `map_tool_call` round-trip ; `bind_endpoint` (D1). Réutilise les tests `InMemoryMailbox` existants. |
+| **app-tauri** | commands ↔ use cases | `submit_agent_input`/`interrupt_agent` mappent bien ; event `AgentBusyChanged` émis ; câblage composition root cohérent (endpoint partagé). |
+| **frontend** (`MediatedInput`, `TerminalView`) | Vitest + RTL, **gateways mock** | entrée détournée hors PTY ; busy désactive Envoyer sans bloquer enqueue ; xterm sortie inchangée ; **sans backend**. |
+
+---
+
+## 9. Risques / points ouverts
+
+1. **Fiabilité de la détection retour-de-prompt** (C5) — le plus dur. Un motif dans la
+   sortie d'un agent peut **faussement** signaler Idle (libère trop tôt) ou ne jamais
+   matcher (reste Busy). *Mitigation* : OR avec le signal explicite `idea_reply` +
+   fallback « reste Busy mais accepte » + timeout par tour. *Reste ouvert* : faut-il un
+   « heartbeat » MCP de fin-de-tour côté CLI ? (hors périmètre immédiat, Claude-only).
+
+2. **Suspension/reprise de session par conversation** (`resumable_id`) — un agent à N
+   fils doit reprendre **le bon** session-id par fil au redémarrage. Dépend du
+   `session{assignFlag,resumeFlag}` du profil (cf. `conversation-resume-architecture`).
+   *Ouvert* : capacité réelle des CLI à tenir N conversations resumables simultanées
+   pour un même process « 1 agent = 1 employé » — possible conflit entre « N fils » et
+   « 1 process ». **Décision de cadrage** : **1 process/agent**, les fils **partagent
+   la file d'entrée** (sérialisés) ; le `resumable_id` par conversation sert surtout à
+   la **reprise au redémarrage**, pas à du vrai parallélisme intra-process.
+
+3. **Deadlock & détection de cycle** (`WaitForGraph`) — couvre A→B→A directs et
+   transitifs, mais le graphe doit être **alimenté en temps réel** (arête posée à
+   l'enqueue, retirée au reply/timeout). *Risque* : arête fantôme si un reply se perd
+   ⇒ faux positif de cycle. *Mitigation* : retrait d'arête garanti par le RAII du tour
+   (comme `_turn` aujourd'hui) + timeout.
+
+4. **Corrélation par ticket vs agents « simples »** — un agent qui ne renvoie pas le
+   `ticket` dans `idea_reply` retombe sur la corrélation positionnelle (tête de file),
+   ambiguë en multi-fil. *Mitigation* : protocole §B-5 (description outil) **insiste**
+   sur le renvoi du ticket ; mono-fil reste correct sans. *Ouvert* : forcer le ticket
+   requis casserait des agents simples — on garde optionnel.
+
+5. **Périmètre FileGuard contournable** — tant que l'agent garde un shell brut (PTY),
+   il peut écrire les `.md`/mémoire **par le filesystem** malgré le verrou MCP. Le
+   verrou n'est étanche que si l'accès fs à ces chemins est **réellement** retiré
+   (sandbox, cf. `agent-permissions-architecture` / Landlock). *Ouvert* : sans sandbox
+   OS, le `FileGuard` est **coopératif** (protège des collisions IdeA↔IdeA, pas d'un
+   agent qui contourne). À acter : FileGuard = correction des collisions **dans le
+   chemin IdeA** d'abord ; étanchéité réelle = lot sandbox ultérieur.
+
+6. **Migration `AgentMailbox` → `InputMediator`** — risque de double-file transitoire.
+   *Mitigation* : `MediatedInbox` **enveloppe** `InMemoryMailbox` (pas de réécriture),
+   `OrchestratorService` bascule d'un `with_mailbox` vers `with_input_mediator` en un
+   lot (C2→C3), tests existants `InMemoryMailbox` conservés verts.
+
+---
+
+*Document maintenu par l'Agent Architecture — cadrage « conversation par paire »,
+base des lots C1→C7 / F1→F2 / D1 avant tout code.*

.ideai/briefs/d4-commandes-bridge-chat.md

@@ -0,0 +1,88 @@
+# Brief Dev — Lot D4 : commandes Tauri + bridge chat (§17.9)
+
+> Demandé par **Main** à **DevBackend** (dev) + **QA** (test). Cycle §3 : code → tests → vert.
+> Périmètre **backend uniquement** (`app-tauri`). Le frontend chat est D5, hors périmètre ici.
+
+## 0. Où on en est
+
+Le fil §17 (exécution structurée des agents IA via le port `AgentSession`) est livré
+jusqu'à **D3 inclus** :
+
+- **D0/D1** (`5e10b5e`) : port `domain::ports::AgentSession` + `AgentSessionFactory`,
+  `ReplyEvent`/`ReplyStream`/`AgentSessionError`, champ `AgentProfile.structured_adapter`,
+  registre `StructuredSessions`, agrégateur `LiveSessions`, helper `send_blocking`.
+- **D2** (`751d94d`) + spikes **S1/S2** (`f104862`) : adapters `ClaudeSdkSession` /
+  `CodexExecSession` dans `crates/infrastructure/src/session/`, fake CLI + harnais de
+  conformité, **formats réels** Claude `stream-json` / Codex `exec --json` câblés.
+- **D3** (`56913b9`) : `LaunchAgent` route structuré vs PTY ; `LaunchAgentOutput` porte
+  désormais `structured: Option<StructuredSessionDescriptor>`.
+
+**D4 = exposer tout ça à l'UI** : commandes Tauri + pont de streaming, jumeau exact du
+chemin PTY existant. Aucun chemin PTY (terminal non-IA) ne doit changer ni régresser.
+
+## 1. Périmètre D4 (réf. §17.7 et tableau §17.9)
+
+À livrer dans `crates/app-tauri/src/` :
+
+1. **`ChatBridge`** — jumeau de `PtyBridge` (`crates/app-tauri/src/pty.rs`), **generation-tracked**
+   (même mécanique de génération pour éviter la double-pompe lors d'une ré-attache). Il pompe
+   un `ReplyStream` (events `ReplyEvent` du port) vers un `tauri::ipc::Channel`, en émettant
+   des `ReplyChunk` (DTO ci-dessous). Vit à côté de `PtyBridge`, ne le remplace pas.
+2. **Commandes Tauri** :
+   - `agent_send(sessionId, prompt)` → pompe les `ReplyEvent` du tour sur le `Channel`
+     (deltas `TextDelta` → chunks, `ToolActivity` → chunks d'activité, `Final` → chunk final
+     qui fige le tour). S'appuie sur le registre `StructuredSessions` / `send_blocking` côté
+     application (déjà livré en D1).
+   - `reattach_agent_chat(...)` → renvoie le scrollback de conversation + rebranche le `Channel`
+     (repeint sans re-spawn ; supersede l'ancienne génération).
+   - `close_agent_session(sessionId)` → `shutdown` (polymorphe) + unregister du registre.
+3. **DTO** (`crates/app-tauri/src/dto.rs`) :
+   - `ReplyChunk` : variantes delta texte / activité outil / final (sérialisation camelCase,
+     cohérente avec les DTO existants).
+   - `ReattachChatDto`.
+   - **`cellKind`** ajouté au DTO de session (terminal `pty` vs chat `chat`), dérivé de la
+     présence d'un descripteur structuré (`LaunchAgentOutput.structured`).
+4. **Wiring composition root** (`state.rs`/`lib.rs`) : injecter les dépendances nécessaires,
+   enregistrer les nouvelles commandes. **Aucun `new ClaudeSdkSession` ici** — passe par la
+   factory déjà injectée (règle D du §17.8).
+
+## 2. Contrat / invariants à respecter
+
+- **Generation supersede** : une ré-attache invalide l'ancienne pompe ; pas de double émission.
+- **`cellKind`** est la seule info dont D5 (frontend) a besoin pour router cellule chat vs
+  terminal. Stable et explicite au DTO.
+- **Isolation parsing** : D4 ne parse aucun format CLI — il consomme des `ReplyEvent` typés.
+- **Zéro régression PTY** : le chemin terminal brut (`PtyBridge`, commandes terminal) reste
+  identique. Les tests PTY existants restent verts.
+- Frontières hexagonales (§17.8) : `app-tauri` dépend des ports/registres application, jamais
+  des adapters infra concrets.
+
+## 3. Tests attendus (QA — réf. colonne « Tests attendus » D4 du §17.9)
+
+Crate `app-tauri` (fakes pour la session structurée, pas de vrai CLI) :
+
+- `agent_send` pompe les events d'un tour sur le `Channel` (séquence deltas… puis `Final`).
+- ré-attache → scrollback conversation repeint, **sans** re-spawn de session.
+- `close_agent_session` → `shutdown` appelé **et** unregister du registre.
+- **generation supersede** : après ré-attache, l'ancienne génération ne pompe plus (pas de
+  double émission sur le `Channel`).
+- DTO : `cellKind` = `chat` pour une sortie `LaunchAgentOutput` avec `structured: Some(..)`,
+  `pty` sinon ; round-trip `ReplyChunk` (camelCase).
+- non-régression : un DTO de session PTY existant sérialise toujours pareil (le nouveau champ
+  `cellKind` ne casse pas les snapshots — vérifier la valeur par défaut/dérivée).
+
+## 4. Méthode
+
+Cycle §3 strict : DevBackend code → QA écrit + exécute les tests → vert avant de clore.
+Rapport d'erreurs clair si rouge → correction → re-test. Commit `feat(agent): … (D4) — §17`
+quand `cargo test --workspace` est vert. **Ne pas push** (validation Main requise).
+
+## 5. Références code
+
+- Jumeau à copier : `crates/app-tauri/src/pty.rs` (`PtyBridge`, generation tracking).
+- Source du flux : `domain::ports::{AgentSession, ReplyEvent, ReplyStream}` ;
+  registre/`send_blocking` : `crates/application/src/agent/structured.rs`.
+- Routage déjà fait : `crates/application/src/agent/lifecycle.rs`
+  (`LaunchAgentOutput.structured`).
+- DTO existants : `crates/app-tauri/src/dto.rs` ; commandes : `crates/app-tauri/src/commands.rs`.
+- Spec complète : `ARCHITECTURE.md` §17.7 (commandes & DTO) et tableau §17.9 ligne **D4**.

.ideai/briefs/d5-frontend-chat.md

@@ -0,0 +1,99 @@
+# Brief Dev — Lot D5 : frontend chat (§17.9)
+
+> Demandé par **Main** à **DevFrontend** (dev) + **QA** (test). Cycle §3 : code → tests → vert.
+> Périmètre **frontend uniquement** (`frontend/src`). Le backend D4 est livré et committé (`f4d5727`).
+
+## 0. Où on en est
+
+Le fil §17 (exécution structurée des agents IA) est livré jusqu'à **D4 inclus** côté backend :
+les commandes Tauri `agent_send` / `reattach_agent_chat` / `close_agent_session` existent et
+streament des `ReplyChunk` sur un `Channel`. D5 = **la vue chat React** qui consomme ça, plus
+le **routage par type de cellule** dans le layout.
+
+### Contrats backend exacts à mirrorer (déjà livrés)
+Commandes Tauri (`crates/app-tauri/src/commands.rs`) :
+- `agent_send(sessionId: string, prompt: string, onReply: Channel<ReplyChunk>) -> void`
+- `reattach_agent_chat(sessionId: string, onReply: Channel<ReplyChunk>) -> ReattachChatDto`
+- `close_agent_session(sessionId: string) -> void`
+
+DTO (`crates/app-tauri/src/dto.rs`) — **sérialisation camelCase tagué `kind`** :
+```ts
+type ReplyChunk =
+  | { kind: "textDelta"; text: string }
+  | { kind: "toolActivity"; label: string }
+  | { kind: "final"; content: string };
+
+// ReattachChatDto : le scrollback de conversation (chunks déjà streamés)
+interface ReattachChatDto { sessionId: string; scrollback: ReplyChunk[]; }
+
+// Et surtout : le DTO de session porte désormais cellKind
+type CellKind = "pty" | "chat";   // toujours présent sur TerminalSessionDto
+```
+> `cellKind` vaut `"chat"` quand l'agent est piloté en mode structuré (profil Claude/Codex),
+> `"pty"` pour un terminal brut. C'est **la seule info dont le frontend a besoin** pour router
+> cellule chat vs terminal.
+
+## 1. Périmètre D5 (réf. tableau §17.9 ligne D5)
+
+1. **`AgentChatView`** (nouveau, `frontend/src/features/chat/`) : vue de conversation IdeA.
+   - Affiche les **deltas live** (accumulation `textDelta` → texte du tour en cours), l'**activité
+     d'outil** (`toolActivity`), et **fige le tour** sur `final`.
+   - Zone de **saisie** d'un prompt → appelle `AgentGateway.sendPrompt`.
+   - **Scrollback de conversation** : à l'attache, repeint l'historique renvoyé par
+     `reattachChat` ; survit à un changement d'onglet/layout (ré-attache, pas re-spawn).
+   - C'est le **jumeau chat** de `TerminalView` (`frontend/src/features/terminals/TerminalView.tsx`,
+     283 l.) — inspire-toi de sa gestion de cycle de vie (mount/attach/detach), mais pour un
+     flux de messages structuré au lieu d'octets xterm.
+2. **Routage par `cellKind` dans `LayoutGrid`** (`frontend/src/features/layout/LayoutGrid.tsx`,
+   fonction `LeafView` ~l.159) : une cellule rend `AgentChatView` si `cellKind === "chat"`,
+   sinon `TerminalView` (comportement actuel inchangé). Le `cellKind` arrive sur le handle/session
+   au lancement (sortie de `launchAgent`) — propage-le jusqu'au leaf.
+3. **Port `AgentGateway`** (`frontend/src/ports/index.ts`, interface ~l.76) : ajoute
+   - `sendPrompt(sessionId: string, prompt: string, onReply: (c: ReplyChunk) => void): Promise<void>`
+   - `reattachChat(sessionId: string, onReply: (c: ReplyChunk) => void): Promise<ReplyChunk[]>`
+   - `closeAgentSession(sessionId: string): Promise<void>`
+   (signatures à aligner avec le style des méthodes existantes `launchAgent`/`reattach`).
+4. **Adapter Tauri** (`frontend/src/adapters/agent.ts`, classe `TauriAgentGateway`) : implémente
+   les 3 méthodes via `invoke(...)` + `new Channel<ReplyChunk>()` (modèle déjà présent pour
+   `launchAgent`/`reattach` qui utilisent `Channel<number[]>`).
+5. **Mock gateway** (`frontend/src/adapters/mock/index.ts`) : streame des `ReplyChunk` scriptés
+   (quelques `textDelta` puis un `final`) pour les tests et le dev hors-Tauri.
+6. **Types TS** : ajoute `ReplyChunk`, `CellKind`, `ReattachChatDto` aux types partagés (là où
+   vivent les autres mirrors de DTO), et le champ `cellKind` sur le type de session/handle.
+
+## 2. Invariants à respecter
+
+- **Zéro régression terminal** : `TerminalView` et le chemin PTY de `LayoutGrid` restent
+  identiques ; une cellule `pty` se comporte exactement comme avant.
+- **Ré-attache ≠ re-spawn** : changer d'onglet puis revenir repeint la conversation depuis le
+  scrollback renvoyé par `reattachChat`, sans relancer de tour (miroir du PTY reattach).
+- **Accumulation correcte** : les `textDelta` s'accumulent dans le tour courant ; `final` clôt
+  le tour (le texte final fait foi). Pas de doublon delta/final affiché deux fois.
+- Frontières : la vue dépend du **port** `AgentGateway`, jamais directement de `invoke`/Tauri
+  (c'est l'adapter qui parle à Tauri). Hexagonal côté front respecté.
+
+## 3. Tests attendus (QA — Vitest, réf. colonne « Tests attendus » D5 du §17.9)
+
+Aligne-toi sur le style des `*.test.tsx` existants (`LayoutGrid.test.tsx`, `TerminalView.test.tsx`,
+`adapters/agent.test.ts`), avec le **mock gateway** :
+- cellule `cellKind:"chat"` rend `AgentChatView` ; `cellKind:"pty"` rend `TerminalView`.
+- les `textDelta` s'accumulent à l'écran → `final` fige le tour.
+- ré-attache repeint le scrollback **sans** re-spawn (le mock ne reçoit pas de nouveau `sendPrompt`).
+- envoi d'un prompt → `AgentGateway.sendPrompt` appelé avec les bons args.
+- `toolActivity` affiché comme activité d'outil.
+- mock gateway streame bien une séquence `ReplyChunk` (deltas… puis final).
+
+## 4. Méthode
+
+Cycle §3 strict : DevFrontend code → QA écrit + exécute les tests Vitest → vert avant de clore.
+Vérifie `npm run build` (tsc --noEmit + vite) **et** `npx vitest run` verts. **Ne pas committer,
+ne pas push** — Main relit et commit. Rapport d'erreurs clair si rouge → correction → re-test.
+
+## 5. Références
+
+- Jumeau à copier : `frontend/src/features/terminals/TerminalView.tsx` (cycle de vie attach/detach).
+- Routage cellule : `frontend/src/features/layout/LayoutGrid.tsx` (`LeafView`).
+- Port : `frontend/src/ports/index.ts` (`AgentGateway`) ; adapter : `frontend/src/adapters/agent.ts` ;
+  mock : `frontend/src/adapters/mock/index.ts`.
+- Backend déjà livré : commit `f4d5727`, `crates/app-tauri/src/{chat,commands,dto}.rs`.
+- Spec : `ARCHITECTURE.md` §17.6 (deux types de cellules) et tableau §17.9 ligne **D5**.

.ideai/briefs/d6-messagerie-inter-agents.md

@@ -0,0 +1,104 @@
+# Brief Dev — Lot D6 : messagerie inter-agents via `send_blocking` (§17.9)
+
+> Demandé par **Main** à **DevBackend** (dev) + **QA** (test). Cycle §3 : code → tests → vert.
+> Périmètre **backend** (domaine + application). Pas de frontend.
+
+## 0. Le trou que D6 comble (important)
+
+Aujourd'hui, « Main demande à Architect » ne **retourne jamais le contenu** de la réponse :
+- `OrchestratorCommand` n'a **pas** de variante « demander/attendre une réponse ». Le wire
+  `agent.run` replie `task` dans `context`, et `context` n'est utilisé que pour un agent **neuf**
+  (`.md` initial) ⇒ pour un agent **déjà existant**, le `task` est **silencieusement ignoré**.
+- La réponse (`*.response.json`) ne porte qu'un **ACK de cycle de vie**
+  (`detail: "launched agent X"`), jamais la sortie produite par la cible.
+
+D6 = brancher la **messagerie synchrone** sur le port `AgentSession` : la cible est pilotée en
+mode structuré, on **attend son tour** et on **renvoie son contenu**. La primitive existe déjà :
+`crate::agent::structured::send_blocking(session, prompt, timeout) -> Result<String, AgentSessionError>`
+(livrée en D1 ; retourne le contenu du `Final`, `Timeout` typé **sans tuer la session**).
+
+## 1. Périmètre D6 (réf. tableau §17.9 ligne D6)
+
+### A. Domaine (`crates/domain/src/`)
+1. **`OrchestratorCommand::AskAgent { target: String, task: String }`** (`orchestrator.rs`,
+   enum ~l.111). Nouvelle variante « j'attends une réponse ».
+2. **Validation** : nouvelle action wire **`agent.message`** → `AskAgent` dans
+   `OrchestratorRequest::validate` (~l.175). `targetAgent` (ou `name`) **et** `task` requis
+   non-vides (sinon `OrchestratorError::MissingField`). Garde le mapping `agent.run` actuel
+   inchangé (lancement fire-and-forget). Ajoute un cas de test de round-trip JSON `agent.message`.
+3. **`DomainEvent::AgentReplied { ... }`** (`events.rs`, à côté de `AgentLaunched`) pour
+   l'observabilité : au minimum le nom/id de l'agent cible et, si pertinent, la taille/preview
+   de la réponse (reste pur, pas de payload lourd imposé — calque le style des variantes voisines).
+
+### B. Application (`crates/application/src/orchestrator/service.rs`)
+4. **`OrchestratorOutcome` gagne le contenu** : ajoute `reply: Option<String>` (l'ACK actuel
+   `detail` reste). Les commandes existantes mettent `reply: None` ; `AskAgent` met
+   `reply: Some(contenu)`. (Champ additif ⇒ aucune régression des call sites/tests existants.)
+5. **`dispatch` route `AskAgent`** :
+   - résous l'agent cible par nom (`find_agent_id_by_name`) → sinon `AppError::NotFound` typé.
+   - cherche sa **session structurée vivante** dans le registre **`StructuredSessions`** (PAS
+     `TerminalSessions`). Si vivante ⇒ `send_blocking(session, &task, timeout)`.
+   - si **pas vivante** ⇒ lance l'agent en mode structuré (via `LaunchAgent`, background) puis
+     `send_blocking`. Respecte l'invariant **1 session/agent**.
+   - si la cible est **PTY-only** (profil sans `structured_adapter` ⇒ pas adressable en `ask`) ⇒
+     **erreur typée explicite** (`AppError::Invalid`/`NotFound` avec message clair « agent X n'est
+     pas pilotable en mode structuré »). C'est acceptable (le menu ne crée plus que des agents
+     structurés, cf. D7 à venir).
+   - **timeout** ⇒ remonte une erreur typée, **sans tuer la session** (déjà la sémantique de
+     `send_blocking`).
+   - en cas de succès ⇒ **publie `DomainEvent::AgentReplied`** sur l'`EventBus`, et retourne
+     `OrchestratorOutcome { detail, reply: Some(content) }`.
+6. **Injection** : le service a besoin du registre `StructuredSessions` + de l'`EventBus` (et de
+   quoi piloter `send_blocking`). **Ajoute-les par builder additif** (`with_structured(...)` /
+   `with_events(...)` façon D3 sur `LaunchAgent`) pour que `OrchestratorService::new` reste
+   compatible et que les tests/call sites legacy restent verts. Câble au composition root
+   (`crates/app-tauri/src/state.rs`).
+
+### C. Nettoyage voie principale
+7. **Aucun accès outbox/inbox** dans le chemin `AskAgent` (le rendez-vous est intrinsèque à
+   `send_blocking`). Les seules occurrences `outbox/inbox` actuelles sont des commentaires de doc
+   dans `agent/structured.rs` — ne ré-introduis rien. Vérifie qu'aucun `AgentReplyChannel`/outbox
+   n'est utilisé.
+
+## 2. Invariants à respecter
+
+- **1 session vivante par agent** across registres (PTY + structuré).
+- **Timeout ne tue jamais la session** (retry possible).
+- **Cible PTY non adressable** par `ask` ⇒ erreur typée, jamais un ACK trompeur ni un panic.
+- Frontières hexagonales : le domaine reste pur (pas d'I/O dans `orchestrator.rs`/`events.rs`) ;
+  l'orchestration vit dans l'application ; aucun `new` d'adapter infra dans le service.
+- **Zéro régression** : `agent.run`/`spawn_agent`/`stop_agent`/`update_agent_context`/`skill.create`
+  inchangés ; le watcher d'orchestration et ses tests restent verts.
+
+## 3. Tests attendus (QA — colonne « Tests attendus » D6 du §17.9)
+
+Unitaires avec **fakes** (fake `AgentSession`, fake registres, fake EventBus — aucun vrai CLI) :
+- cible **vivante** (session structurée enregistrée) ⇒ `send_blocking` appelé, `reply: Some(...)`
+  porte le contenu du `Final`.
+- cible **morte** ⇒ `LaunchAgent` invoqué (structuré) **puis** `send` ; `reply` renvoyé.
+- **timeout** ⇒ erreur typée remontée, **session non tuée** (le fake atteste qu'aucun `shutdown`
+  n'a été appelé), pas de `reply`.
+- **`AgentReplied`** publié sur l'EventBus en cas de succès.
+- cible **PTY-only** (profil sans adapter / présente seulement dans `TerminalSessions`) ⇒ erreur
+  typée explicite, **pas** d'ACK « launched ».
+- **validation** : `agent.message` sans `task` ⇒ `MissingField` ; round-trip JSON `agent.message`.
+- **non-régression** : `agent.run` ne change pas de comportement ; aucun accès outbox.
+- garde anti-always-green sur au moins l'invariant timeout-ne-tue-pas OU ask-retourne-le-contenu.
+
+## 4. Méthode
+
+DevBackend code → vérifie `cargo build -p domain -p application -p app-tauri`. **N'exécute pas
+`cargo test --workspace`** si un build concurrent tient le lock (sinon, lance-le). QA écrit + exécute
+les tests, produit un rapport clair si rouge. **Ne pas committer, ne pas push** — Main relit et commit.
+
+## 5. Références
+
+- Domaine : `crates/domain/src/orchestrator.rs` (enum `OrchestratorCommand` ~l.111, `validate`
+  ~l.175), `crates/domain/src/events.rs` (`DomainEvent`).
+- Application : `crates/application/src/orchestrator/service.rs` (struct/deps ~l.37, `dispatch`
+  ~l.88, `OrchestratorOutcome` ~l.50, `spawn_agent` comme modèle de résolution d'agent).
+- Primitive : `crates/application/src/agent/structured.rs` (`send_blocking`).
+- Registre structuré : `StructuredSessions` (livré D1, jumeau de `TerminalSessions`) — repère-le
+  et lis son API avant de t'en servir.
+- Composition root : `crates/app-tauri/src/state.rs`.
+- Spec : `ARCHITECTURE.md` §17.4 (réconciliation §16) et tableau §17.9 ligne **D6**.

.ideai/briefs/d7-menu-restreint.md

@@ -0,0 +1,95 @@
+# Brief Dev — Lot D7 : menu de profils restreint + retrait custom (§17.9)
+
+> Demandé par **Main** à **DevBackend** + **DevFrontend** + **QA**. Cycle §3.
+> Dernier lot de §17. **Back + front.** DevBackend livre le contrat, DevFrontend consomme.
+
+## 0. Objectif (§17.3 / §17.6)
+
+Tant que seuls Claude et Codex ont un adapter structuré, le **menu de sélection de profil IA**
+ne doit proposer **que** des profils pilotables en mode structuré. Conséquences :
+- **Gemini / Aider** (présents dans le catalogue de référence mais **sans** `structured_adapter`)
+  ne sont **plus proposés** à la sélection.
+- Le **profil custom** est **retiré** (l'utilisateur ne peut plus saisir une commande arbitraire,
+  car on ne saurait pas la piloter en structuré).
+
+Principe : `is_selectable(profile) == structured_adapter.is_some()` (équivaut à
+`AgentSessionFactory::supports(profile)`). C'est ce prédicat qui **filtre la liste exposée**
+(wizard first-run **et** création/édition d'agent).
+
+> Note : on **ne casse pas** le modèle `AgentProfile` (un profil sans adapter reste un profil
+> PTY/legacy valide, §17.3). On restreint seulement ce qui est **proposé à la sélection**.
+
+## 1. Côté DevBackend (`crates/`)
+
+1. **Prédicat de sélectionnabilité** centralisé : `is_selectable(&AgentProfile) -> bool`
+   (= `structured_adapter.is_some()`). Place-le là où c'est cohérent (catalogue/usecases agent).
+   Évite de dupliquer la logique ; si `AgentSessionFactory::supports` existe déjà (livré D2),
+   garde la **même sémantique** (les deux doivent rester d'accord).
+2. **Exposer uniquement les profils sélectionnables** au chemin de sélection : le use case qui
+   alimente le wizard/la création (autour de `ReferenceProfiles` / `reference_profiles()` dans
+   `crates/application/src/agent/{catalogue,usecases}.rs`) doit **filtrer** sur `is_selectable`.
+   Gemini/Aider restent dans le catalogue **data** (ne les supprime pas du modèle) mais
+   **n'apparaissent pas** dans la liste proposée. Décide proprement : soit un nouveau champ
+   `selectable: bool` sur le DTO exposé, soit une liste déjà filtrée — choisis l'option la moins
+   ambiguë pour le front et documente-la.
+3. **Retrait custom (back)** : si une commande/usecase accepte un profil custom arbitraire pour
+   la sélection/création depuis le wizard, neutralise ce chemin (ou documente qu'il n'est plus
+   appelé). Ne casse pas la persistance de profils existants.
+4. Vérifie `cargo build -p domain -p application -p app-tauri`.
+
+**Contrat à livrer à DevFrontend** (à mettre dans ton rapport) : la forme exacte de ce que le
+front reçoit (liste filtrée ? champ `selectable`/`structuredAdapter` sur `ProfileDto` ?) pour
+qu'il sache quoi afficher et quoi masquer. Rappel : `ProfileDto(pub AgentProfile)` sérialise déjà
+`structuredAdapter` (camelCase) — tu peux t'appuyer dessus plutôt que d'ajouter un champ.
+
+## 2. Côté DevFrontend (`frontend/src/`)
+
+> **Ne démarre qu'après le contrat de DevBackend** (Main te relaiera la forme exacte).
+
+1. **Wizard first-run** (`features/first-run/FirstRunWizard.tsx`, `ProfilesSettings.tsx`) :
+   - n'affiche que les profils **sélectionnables** (Claude/Codex) ;
+   - **retire le bloc `AddCustomProfile`** (`onAdd`/`vm.addCustom`, `emptyCustomProfile`,
+     `aria-label="add custom profile"`) — le bouton/forme custom **disparaît**.
+2. **Sélecteur d'agent** (création/édition dans `features/agents/`) : même filtre — seuls
+   Claude/Codex proposés ; pas d'option custom.
+3. Nettoie le code mort résultant (helpers `emptyCustomProfile`, validation custom) **uniquement**
+   s'il n'est plus référencé ailleurs — sinon laisse-le et signale-le.
+4. Vérifie `cd frontend && npm run build`.
+
+## 3. Invariants
+
+- **Zéro régression** : la persistance/édition des profils déjà configurés n'est pas cassée ;
+  un projet existant avec un agent Gemini/Aider/custom **legacy** continue de fonctionner (on
+  restreint la **création**, pas l'exécution de l'existant).
+- Le prédicat `is_selectable` est la **source unique** ; back et front doivent rester cohérents.
+- Frontières : le front filtre/affiche selon le contrat du port, le back décide la sélectionnabilité.
+
+## 4. Tests attendus (QA)
+
+**Rust** (`-p application`/`app-tauri`) :
+- `is_selectable` vrai pour Claude/Codex, faux pour Gemini/Aider.
+- la liste exposée à la sélection ne contient **que** Claude/Codex (custom absent).
+- non-régression : `reference_profiles()` (catalogue brut) contient toujours les 4 (data intacte).
+
+**Vitest** (`frontend`) :
+- le wizard first-run n'affiche que Claude/Codex ; **le bloc custom est absent**
+  (`aria-label="add custom profile"` introuvable).
+- le sélecteur de création d'agent ne propose que Claude/Codex, pas de custom.
+- garde anti-always-green : un test qui vérifie l'**absence** du custom doit échouer si le bloc
+  réapparaît (assertion sur non-présence d'un testid/label précis).
+
+## 5. Méthode
+
+DevBackend → contrat + build vert → Main relaie à DevFrontend → build vert → QA écrit+exécute
+(`cargo test --workspace` ET `npx vitest run`) → vert. Rapport d'erreurs clair si rouge.
+**Ne pas committer, ne pas push.**
+
+## 6. Références
+- Catalogue : `crates/application/src/agent/catalogue.rs` (`reference_profiles()` : claude+codex
+  `with_structured_adapter`, gemini+aider sans) ; use cases : `…/agent/usecases.rs`
+  (`ReferenceProfiles`).
+- Factory : `AgentSessionFactory::supports` (livré D2, `crates/infrastructure/src/session/factory.rs`).
+- DTO : `crates/app-tauri/src/dto.rs` (`ProfileDto`/`ProfileListDto`).
+- Front : `frontend/src/features/first-run/{FirstRunWizard,ProfilesSettings}.tsx`,
+  `frontend/src/features/agents/`, `frontend/src/domain/index.ts` (`emptyCustomProfile`).
+- Spec : `ARCHITECTURE.md` §17.3, §17.6 et tableau §17.9 ligne **D7**.

.ideai/briefs/option1-terminal-mcp-design.md

@@ -0,0 +1,48 @@
+# Design — Option 1 « Terminal + MCP » (orchestration inter-agents)
+
+> Décision produit arbitrée (2026-06-11). Remplace la vue chat structurée par le
+> terminal natif + délégation inter-agents par outils MCP. Source : agent Architecte.
+> Statut : **design validé, dev NON commencé** (limite de session atteinte le 2026-06-11,
+> reset 3:40am Europe/Paris). Reprendre par les lots backend B-0→B-5 et frontend F-1.
+
+## Objectif
+- **Vue humaine = terminal brut natif** (PTY interactif). Réflexion live + Échap = natifs CLI, zéro parsing par modèle. On abandonne `AgentChatView`/stream-json comme vue.
+- **Délégation cross-model via MCP** : `idea_ask_agent(target, task)` bloquant → la cible traite quand libre (FIFO) → rend son résultat via NOUVEL outil `idea_reply(result)` → IdeA débloque l'appelant. Fin-de-tour = signal MCP explicite.
+- Principes : 1 agent = 1 employé (1 process/session, input FIFO) ; hexagonal + SOLID stricts ; plus aucun `parse_event` requis pour vue ni orchestration.
+
+## Découvertes clés de l'architecte (état réel du code)
+1. La **file FIFO existe déjà** : `OrchestratorService` (`crates/application/src/orchestrator/service.rs`) a `ask_locks: Mutex<HashMap<AgentId, Arc<AsyncMutex<()>>>>` + `ask_lock_for()` + `ASK_QUEUE_WAIT_CAP` (600s) + `ASK_AGENT_TIMEOUT` (300s). On la formalise en port `AgentMailbox` (pour porter un `oneshot` de réponse).
+2. `idea_ask_agent` → `agent.message` → `OrchestratorCommand::AskAgent{target_agent, task}` **déjà câblé** (mcp/tools.rs, domain/orchestrator.rs, service.rs). On réimplémente le **corps** de `ask_agent()`.
+3. Aujourd'hui `ask_agent` **exige une session structurée** et renvoie `AppError::Invalid` si la cible est en PTY brut (service.rs ~400-410). **Inverser cette branche** : PTY vivant = canal normal.
+4. Routage structuré dans `crates/application/src/agent/lifecycle.rs` (`LaunchAgent` ~1100). Levier de bascule : **ne plus injecter la fabrique structurée au composition root** (`crates/app-tauri/src/state.rs`, `with_structured`).
+5. `apply_mcp_config` (lifecycle.rs ~1391) écrit déjà `.mcp.json` + `--mcp-config` AVANT le spawn, **chemin PTY inclus** → la CLI PTY a déjà le serveur MCP IdeA (à vérifier par test B-0). Vigilance : `ensure_mcp_server` doit piloter `McpServer::serve` sur le loopback.
+6. `idea_reply` n'existe nulle part : seul vrai ajout de surface.
+
+## Lots BACKEND (Rust — agent dev backend) ; NE PAS faire B-6 (nettoyage) avant coordination
+- **B-0** Prérequis transport MCP : garantir CLI PTY reçoit `--mcp-config <path>` (endpoint/project/requester) + `serve` piloté loopback. Test : CLI factice PTY appelle `idea_list_agents`, reçoit réponse.
+- **B-1** Port `AgentMailbox` + `InMemoryMailbox`. Domaine pur (`crates/domain/src/mailbox.rs` ou ports.rs) : trait + `Ticket{id,requester,task}`, `TicketId`, `MailboxError`. Infra (`crates/infrastructure/src/mailbox/`) : `HashMap<AgentId, VecDeque<(Ticket, oneshot::Sender<String>)>>` + mutex ; `enqueue` rend `PendingReply` (sur `oneshot::Receiver`). Tests : FIFO ; `resolve` réveille le bon pending ; 2 ask même cible sérialisés ; cibles ≠ non bloquants ; timeout retire ticket de tête.
+- **B-2** Bascule routage : tous en PTY. `state.rs` : retirer `with_structured` de `LaunchAgent`/`OrchestratorService`/`ChangeAgentProfile`. Tests : profil Claude → PTY ; DTO renvoie `CellKind::Pty`. Ne pas supprimer `launch_structured` (mort-code, nettoyage ultérieur).
+- **B-3** Réimplémenter `ask_agent` : résoudre id → `mailbox.enqueue` → ticket en tête → garantir cible vivante PTY (sinon LaunchAgent PTY bg) → `PtyPort::write` préfixe `[IdeA · tâche de {A} · ticket {id}] {task}\n` → `await PendingReply` borné `ASK_AGENT_TIMEOUT`. PTY vivant = normal. Timeout : garder agent vivant, retirer ticket de tête. Publier `AgentReplied`. Injecter `Arc<dyn AgentMailbox>` + `Arc<dyn PtyPort>`. Tests : injection bon handle ; agent mort relancé ; timeout libère file ; AgentReplied.
+- **B-4** Outil/action `idea_reply` : `ToolDef idea_reply` (schéma `{result:string}` seul, pas de ticket_id exposé), action wire `agent.reply`, `OrchestratorCommand::Reply{from:AgentId, result}`, `validate`, `map_tool_call` (passe `requester` du handshake comme `from`), bras dispatch → `mailbox.resolve(from, result)`. Corrélation implicite : `idea_reply` résout le ticket en tête de la file de l'émetteur (identité via handshake, pas via id géré par le modèle). `tool_returns_reply` : idea_reply = ACK sans inline. Tests : mapping ; validate exige result ; resolve corrèle tête ; reply sans ask = erreur typée (pas de panic).
+- **B-5** Protocole délégation dans le contexte : injecter dans convention file (`apply_injection`) + description outil : « reçois `[IdeA · tâche …]` → traite → appelle IMPÉRATIVEMENT `idea_reply(result=…)` ; ne réponds jamais qu'en texte. » Test : convention file contient l'instruction.
+
+## Lots FRONTEND (TS/React — agent dev frontend) ; NE PAS faire F-2 (suppression) avant coordination
+- **F-1** Router toute cellule agent vers `TerminalView` (jamais `AgentChatView`) ; ré-attache PTY + scrollback OK. Backend renverra `cellKind:"pty"`. Lire `frontend/src/features/layout/LayoutGrid.tsx`, `features/chat/AgentChatView.tsx`, `TerminalView`, `adapters/agent.ts`, `ports/index.ts`, `domain/index.ts`. Laisser `AgentChatView` inerte (non monté), pas supprimé. Tests Vitest : agent rend `TerminalView`, jamais `AgentChatView` ; re-mount repeint pty.
+
+## Ordre / dépendances
+```
+B-0 ─┬─ B-2 ─┬─ B-3 ─ B-4 ─ B-5
+B-1 ─┘       └─ F-1
+Nettoyage (B-6, F-2) en dernier, coordonné.
+```
+Chemin critique : B-0 → B-2 → B-3 → B-4 → B-5. B-1 ∥ B-0. F-1 dès B-2.
+
+## Cohérence
+Domaine sans I/O (port + entités pures) ; oneshot/PTY/MCP = infra ; application via ports. Open/Closed (idea_reply = ajout, dispatch intact) ; Liskov (Claude/Codex identiques derrière PTY+MCP) ; 1 process/agent préservé.
+
+## Fichiers à toucher
+- Domaine : `mailbox.rs` (nouveau) / `ports.rs` ; `orchestrator.rs` (variante `Reply` + action `agent.reply`).
+- Application : `orchestrator/service.rs` (ask_agent + reply + injection ports) ; `agent/structured.rs` (supprimé au nettoyage) ; `agent/lifecycle.rs` (routage).
+- Infra : `mailbox/` (nouveau) ; `orchestrator/mcp/tools.rs` (idea_reply) ; `orchestrator/mcp/server.rs` (passer requester).
+- app-tauri : `state.rs` (retrait with_structured + injection mailbox + ensure_mcp_server) ; `commands.rs`/`dto.rs` (nettoyage ultérieur).
+- Frontend : `features/layout/LayoutGrid.tsx` (routage TerminalView) ; `features/chat/*` (nettoyage ultérieur).

.ideai/briefs/orchestration-v3-cadrage.md

@@ -0,0 +1,280 @@
+# Cadrage Architecture — Orchestration v3 : invocation native d'agents (surface MCP)
+
+> Produit par **Architect** en réponse au brief `orchestration-v3-invocation-native.md`.
+> Cadrage **avant tout code** (méthode §3). Livrable : ce document + mise à jour `ARCHITECTURE.md` §14.3.
+> Aucun code de production ici.
+
+---
+
+## 0. État réel du terrain — ce qui est DÉJÀ résolu (lu dans le code, pas présumé)
+
+Le brief décrit trois faiblesses (conscience = prose, pas de discussion inter-agents,
+fire-and-forget). **Deux des trois sont déjà comblées par le pivot §17** (livré, lots D0→D7).
+Il faut le constater honnêtement pour ne **pas re-cadrer** ce qui existe :
+
+| Faiblesse du brief | Statut réel | Référence code |
+|---|---|---|
+| Pas de discussion inter-agents (`agent.message` « future », `task` ignoré pour agent vivant) | ✅ **RÉSOLU** | `OrchestratorCommand::AskAgent` (`domain/src/orchestrator.rs`), `OrchestratorService::ask_agent` (`application/src/orchestrator/service.rs`) |
+| Fire-and-forget, pas de corrélation requête↔réponse | ✅ **RÉSOLU sans outbox** : le rendez-vous synchrone est **intrinsèque** à `AgentSession::send()` (flux → `Final` déterministe). Le `Final` *est* la fin de tour. | `application/src/agent/structured.rs` (`send_blocking`), `domain/src/ports.rs` (`ReplyEvent::Final`) |
+| Pas de réveil du demandeur / event de réponse | ✅ **RÉSOLU** | `DomainEvent::AgentReplied`, `OrchestratorResponse.reply` (`infrastructure/src/orchestrator/mod.rs`) |
+| Conscience = soft prompt (l'agent doit deviner le schéma JSON) | ⚠️ **PARTIEL** : la prose `# Orchestration IdeA` est injectée (`compose_convention_file`), mais **aucun outil typé natif** n'est exposé. | `application/src/agent/lifecycle.rs` |
+| Interdiction des subagents natifs **+** alternative native | ⚠️ **PARTIEL** : interdiction présente (prose) ; l'alternative native (outils `idea_*`) **manque encore**. | idem |
+| Capacité MCP sur le profil | ❌ **ABSENT** | — |
+| Serveur MCP / config MCP par CLI | ❌ **ABSENT** | — |
+
+**Conclusion de cadrage** : l'orchestration v3 **n'est plus** « combler la messagerie inter-agents »
+(c'est fait). Elle se réduit à **un seul chantier net** : **exposer l'orchestration IdeA comme
+serveur MCP model-agnostic**, en tant qu'**adapter entrant supplémentaire** par-dessus le **même**
+`OrchestratorService::dispatch`, avec **repli homogène** sur le protocole fichier `.ideai/requests`
+(§14.3) + prose (`compose_convention_file`) pour les CLI sans MCP. C'est ce que cadre la suite.
+
+> **Principe directeur (zéro régression, §9/§17.3)** : MCP est un **confort de conscience native**
+> (outils typés, plus de schéma à deviner). Il **n'invente aucune sémantique** : tout outil MCP se
+> ramène à un `OrchestratorCommand` déjà existant. La voie principale du *retour de valeur* reste
+> §17 (`send_blocking`) ; MCP ne fait que **déclencher** `dispatch`, jamais re-router la réponse.
+
+---
+
+## 1. Décisions tranchées (les 4 points durs du brief)
+
+### Décision 1 — Capacité MCP par runtime = champ optionnel `mcp` sur `AgentProfile` (Open/Closed)
+
+**Tranché** : on ajoute un champ **optionnel** `mcp: Option<McpCapability>` sur `AgentProfile`,
+exactement comme `session: Option<SessionStrategy>` et `structured_adapter: Option<StructuredAdapter>`
+le sont déjà. `None` (défaut) ⇒ **repli fichier + prose** (comportement actuel, zéro régression).
+`Some(_)` ⇒ IdeA matérialise la config MCP de cette CLI au lancement et l'agent voit les outils `idea_*`.
+
+```rust
+// domain/src/profile.rs — capacité MCP déclarative (pur, validé par constructeur, comme SessionStrategy)
+
+/// Stratégie de matérialisation de la config MCP propre à UNE CLI : chaque CLI
+/// déclare son serveur MCP différemment (fichier `.mcp.json` pour Claude Code,
+/// flag de lancement, ou variable d'env). Déclaratif = donnée, pas code (§9).
+#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
+#[serde(rename_all = "camelCase", tag = "strategy")]
+pub enum McpConfigStrategy {
+    /// Écrire un fichier de conf MCP au chemin (relatif au run dir isolé §14.1)
+    /// attendu par la CLI, au format JSON propre à cette CLI (ex. `.mcp.json`).
+    ConfigFile { target: String },          // relative_safe(target) — pas de `..`, pas d'absolu
+    /// Passer le serveur via un flag de lancement (ex. `--mcp-config {path}`).
+    Flag { flag: String },                  // non_empty(flag)
+    /// Passer via une variable d'environnement.
+    Env { var: String },                    // valid_env_var(var)
+}
+
+/// Capacité MCP d'un profil : COMMENT déclarer le serveur MCP IdeA à cette CLI,
+/// et QUEL transport. `None` sur le profil ⇒ repli fichier `.ideai/requests` + prose.
+#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
+#[serde(rename_all = "camelCase")]
+pub struct McpCapability {
+    /// Comment matérialiser la config MCP au lancement (relatif au run dir).
+    pub config: McpConfigStrategy,
+    /// Transport du serveur MCP IdeA (détail invisible au domaine ; voir D3).
+    /// `stdio` = défaut robuste cross-OS ; `socket` = optimisation (point ouvert).
+    #[serde(default)]
+    pub transport: McpTransport,
+}
+
+#[derive(Debug, Clone, Copy, PartialEq, Eq, Default, Serialize, Deserialize)]
+#[serde(rename_all = "camelCase")]
+pub enum McpTransport { #[default] Stdio, Socket }
+```
+
+Sur `AgentProfile`, additif et **non cassant** (sérialisation inchangée pour les profils sans MCP) :
+```rust
+#[serde(default, skip_serializing_if = "Option::is_none")]
+pub mcp: Option<McpCapability>,
+```
+Builder additif (comme `with_structured_adapter`) : `AgentProfile::new(...).with_mcp(cap)` ; la
+signature de `AgentProfile::new` reste **inchangée** ⇒ tous les appels du catalogue/tests restent verts.
+
+**Justification** : cohérence §9 (« ajouter une IA = donnée, pas code »), symétrie avec les deux autres
+capacités optionnelles déjà sur le profil, `skip_serializing_if = None` ⇒ **zéro régression** de
+sérialisation. Le **prédicat de surface** est `profile.mcp.is_some()` — un seul point de vérité.
+
+> **Modèle en couches (exigé par le brief §4.1)** : la surface effective d'un agent est
+> `surface(agent) = if profile.mcp.is_some() { Mcp } else { FileProtocol }`. Les deux couches
+> produisent le **même** `OrchestratorCommand`. Aucun agent n'est jamais bloqué : sans MCP, la prose
+> `# Orchestration IdeA` + `.ideai/requests` reste pleinement fonctionnelle.
+
+---
+
+### Décision 2 — Retour synchrone d'`ask` = AUCUN nouveau modèle de corrélation : on réutilise `send_blocking`
+
+**Tranché (et c'est la décision la plus importante)** : l'outil MCP `idea_ask_agent` **ne crée
+aucune corrélation requête↔réponse, aucun outbox, aucun event de réveil neufs**. Il appelle le
+**même** `OrchestratorService::dispatch(AskAgent { target, task })` que le watcher fichier, qui
+**retourne déjà** `OrchestratorOutcome { reply: Some(content) }` via `send_blocking`. L'adapter MCP
+**renvoie ce `content` inline** comme valeur de retour de l'outil. Fin.
+
+Le brief (rédigé avant le pivot §17) supposait qu'`ask` était un point dur à résoudre via outbox +
+corrélation fichier. **Le pivot §17 l'a déjà tranché autrement** : le `Final` du `ReplyStream` *est*
+la fin de tour déterministe ; pas besoin de deviner, pas d'outbox, pas de `request_id`. On **n'y
+revient pas**. Le tableau ci-dessous fige la sémantique, déjà implémentée :
+
+| Aspect | Décision (déjà en place) | Code |
+|---|---|---|
+| **Corrélation** | Aucune : `dispatch` est un appel synchrone `async` ; la réponse est la valeur de retour. Le transport MCP (JSON-RPC) porte nativement la corrélation requête/réponse. | `service.rs::ask_agent` |
+| **Outbox** | **Supprimé de la voie principale** (§17.4). Pas réintroduit. | — |
+| **Event `AgentReplied`** | **Observabilité UI uniquement** (« Architect a répondu à Main »), best-effort, ne porte pas la valeur. | `reply_outcome` |
+| **Timeout** | Borné (`ASK_AGENT_TIMEOUT = 300 s`). À l'expiration : `AgentSessionError::Timeout` → la cible **reste vivante** (non tuée), l'outil MCP renvoie une **erreur typée** ; l'appelant décide. | `send_blocking` |
+| **Cible a déjà une session vivante** (one-live-session-per-agent) | `ask` **réutilise** la session structurée vivante (`session_for_agent`) — rendez-vous direct, pas de respawn. Si la cible est vivante en **PTY brut** (profil sans `structured_adapter`) ⇒ erreur typée explicite (**jamais** un ACK trompeur). | `service.rs::ask_agent` étapes 1→3 |
+| **Cible morte** | `LaunchAgent` en mode structuré (background) puis `send_blocking`. Garde d'unicité sur **les deux** registres. | idem |
+
+**Justification** : DRY radical (une seule logique de rendez-vous, partagée par UI chat, watcher
+fichier et MCP) ; frontière nette (le domaine ne connaît qu'un `prompt` et un `Final`, jamais un
+transcript ni un id de corrélation) ; universalité (marche pour toute CLI structurée Claude/Codex).
+**Le seul travail v3 ici est de brancher l'outil MCP sur `dispatch` — pas de re-cadrer le rendez-vous.**
+
+> **Conséquence produit** : `idea_ask_agent` cible **toujours un agent structuré** (Claude/Codex),
+> cohérent avec le menu restreint §17.3/§17.6. Un agent **demandeur** peut être n'importe quelle CLI
+> MCP (Claude, Codex, Gemini…) ; un agent **cible** d'un `ask` doit être structuré. C'est déjà
+> l'invariant en vigueur — MCP ne le change pas.
+
+---
+
+### Décision 3 — MCP vs subagents natifs : on garde l'interdiction ET on offre l'alternative native, config injectée par CLI au lancement
+
+**Tranché** : l'interdiction des subagents natifs (prose `# Orchestration IdeA`) **reste** — elle
+protège l'identité/mémoire/observabilité IdeA. Mais on offre désormais la **vraie alternative
+native** : les outils `idea_*` apparaissent dans la liste d'outils de la CLI. La prose est **adaptée
+selon la surface** :
+- agent **MCP** (`profile.mcp.is_some()`) : la prose pointe vers les outils `idea_ask_agent` /
+  `idea_launch_agent` / `idea_list_agents` (au lieu d'« écris un JSON dans `.ideai/requests` »).
+- agent **fichier** (`mcp == None`) : prose `.ideai/requests` actuelle, **inchangée**.
+
+**Injection de la config MCP par CLI = au `LaunchAgent`, dans le run dir isolé (§14.1), via la
+`McpConfigStrategy`** — exactement le même point et la même mécanique que le convention file :
+```
+LaunchAgent::execute (après apply_injection, avant spawn/factory.start) :
+  if let Some(mcp) = &profile.mcp:
+      // IdeA matérialise SA config MCP au format de CETTE CLI dans <run_dir>/...
+      apply_mcp_config(mcp, &run_dir, &spec)   // ConfigFile→write ; Flag→spec.args ; Env→spec.env
+```
+- `ConfigFile { target }` : écrit `<run_dir>/<target>` (ex. `.mcp.json`) avec la déclaration du
+  serveur MCP IdeA (commande/transport). Non-clobbering, best-effort, **comme le seed de permissions**.
+- `Flag { flag }` : ajoute le flag + chemin au `SpawnSpec.args`.
+- `Env { var }` : ajoute la variable au `SpawnSpec.env`.
+
+Le **serveur MCP lui-même** est démarré **par projet ouvert**, à côté du `FsOrchestratorWatcher`,
+dans le **même hook** `ensure_orchestrator_watch` (`app-tauri/src/state.rs`). Une CLI qui se lance
+avec la config injectée se connecte à ce serveur (stdio : IdeA spawn un pont par session ; socket :
+adresse partagée — détail d'adapter, point ouvert S-MCP).
+
+**Justification** : symétrie totale avec le convention file et le seed de permissions (même run dir,
+même best-effort non-clobbering, même moment) ⇒ aucune nouvelle plomberie de cycle de vie. La config
+MCP est **donnée déclarative par profil**, donc « ajouter une CLI MCP = donnée, pas code ».
+
+---
+
+### Décision 4 — Frontières hexagonales : le serveur MCP est un adapter entrant d'infrastructure ; AUCUN nouveau port applicatif
+
+**Tranché** : le serveur MCP est un **driving adapter d'infrastructure**
+(`infrastructure/src/orchestrator/mcp/`), **pair** du `FsOrchestratorWatcher`. Il appelle le **même**
+`OrchestratorService::dispatch` (application) et **ne duplique rien**. Trois portes d'entrée
+substituables se ramènent au même `OrchestratorCommand` :
+
+```
+                 ┌─────────────────────────────────────────────┐
+   Agent MCP ───▶│  Serveur MCP (infra/orchestrator/mcp)        │──┐
+                 └─────────────────────────────────────────────┘  │
+                 ┌─────────────────────────────────────────────┐  │   OrchestratorCommand
+   Fichier   ───▶│  FsOrchestratorWatcher (infra/orchestrator) │──┼──▶ OrchestratorService::dispatch
+   (.ideai/      └─────────────────────────────────────────────┘  │   (application — INCHANGÉ)
+    requests)    ┌─────────────────────────────────────────────┐  │         │
+   UI        ───▶│  Commandes Tauri (app-tauri)                 │──┘         ▼
+                 └─────────────────────────────────────────────┘     use cases agent/terminal
+```
+
+- **Où vit le serveur MCP** : `infrastructure/src/orchestrator/mcp/`. Il **traduit** un appel d'outil
+  MCP (`idea_ask_agent`, `idea_launch_agent`, `idea_list_agents`, et par parité `idea_update_context`,
+  `idea_create_skill`, `idea_stop_agent`) en `OrchestratorCommand`, appelle `dispatch`, et renvoie
+  `OrchestratorOutcome` (`reply`/`detail`) inline comme résultat d'outil. JSON-RPC, stdio/socket,
+  le crate MCP : **tout reste dans cet adapter**. Le domaine/application ignorent MCP.
+- **Quel port côté domaine/application** : **aucun nouveau**. `OrchestratorService::dispatch`
+  (application) est déjà l'unique seam. `idea_list_agents` réutilise `ListAgents`. La validation
+  (`OrchestratorRequest::validate`) reste le point unique « parse, don't validate » — l'adapter MCP
+  construit un `OrchestratorCommand` (directement, ou via `OrchestratorRequest` pour réutiliser la
+  validation, au choix d'implémentation).
+- **Réutilisation de `OrchestratorService` plutôt que duplication** : le serveur MCP reçoit
+  `Arc<OrchestratorService>` au composition root (`state.rs`), exactement comme le watcher. Une seule
+  logique applicative ; les adapters ne portent que leur techno d'entrée.
+
+**Justification** : DRY + règle de dépendance hexagonale. Cible, identité, mémoire, observabilité UI
+passent **toujours** par le seul chemin applicatif. Les spikes MCP (transport, crate) sont **confinés**
+à l'adapter infra et ne touchent ni le domaine ni l'application.
+
+---
+
+## 2. Modèle de messages corrélés — état figé (rien de neuf)
+
+La « corrélation requête↔réponse » du brief est portée **nativement par le transport** :
+- **MCP** : JSON-RPC corrèle requête/réponse par `id` de message ⇒ rien à modéliser côté IdeA.
+- **Fichier** : `<file>.json` → `<file>.json.response.json` (sibling), déjà en place.
+- **Valeur de retour** : `OrchestratorOutcome { detail, reply }` (application) → `OrchestratorResponse
+  { ok, action, detail, error, reply }` (infra fichier) **ou** résultat d'outil MCP. **Structs déjà
+  définies**, réutilisées telles quelles.
+
+Aucun `CorrelationId`, aucun `AgentReply`, aucun port `AgentReplyChannel`, aucun outbox : **abandonnés
+par le pivot §17** et **non réintroduits** par v3. C'est la simplification clé.
+
+---
+
+## 3. Découpage en LOTS testables (méthode §3) — MCP uniquement
+
+> Chaque lot = binôme dev+test, vert avant le suivant. Backend/frontend séparés.
+> Les terminaux non-IA et le chemin fichier `.ideai/requests` restent verts à chaque lot.
+> **Spike S-MCP** (crate MCP Rust + transport stdio/socket + format de conf par CLI) est **confiné au
+> lot M2** et n'invalide pas l'ossature (le contrat d'entrée reste `OrchestratorCommand`).
+
+| Lot | Côté | Périmètre | Crates/dossiers | Contrats | Tests attendus |
+|---|---|---|---|---|---|
+| **M0 (capacité profil)** | back | `McpCapability` + `McpConfigStrategy` + `McpTransport` (domaine, validés) ; champ `AgentProfile.mcp: Option<McpCapability>` (+ builder `with_mcp`, `new` inchangé) ; catalogue Claude/Codex annotés (ex. `ConfigFile { target: ".mcp.json" }`). | `domain/src/profile.rs`, `application/src/agent/catalogue.rs` | enum + struct + champ optionnel sérialisé | unit purs : `mcp = None` round-trip **identique à avant** (zéro régression sérialisation) ; `Some(_)` round-trip ; constructeurs valident (`relative_safe` target, `non_empty` flag, `valid_env_var`) ; catalogue annoté. |
+| **M1 (injection conf MCP au lancement)** | back | `LaunchAgent` matérialise la conf MCP selon `McpConfigStrategy` dans le run dir isolé (après `apply_injection`, avant spawn/`factory.start`) : `ConfigFile`→write non-clobbering, `Flag`→`args`, `Env`→`env`. Prose `compose_convention_file` adaptée selon `mcp.is_some()`. | `application/src/agent/lifecycle.rs` | `LaunchAgent` (chemin MCP additif) | unit (fakes) : profil `mcp=None` ⇒ **aucun** write/flag/env MCP (chemin actuel inchangé) ; `ConfigFile` ⇒ fichier écrit au bon chemin, non-clobbering ; `Flag`/`Env` ⇒ `spec` enrichi ; prose contient les outils `idea_*` si MCP, sinon `.ideai/requests`. |
+| **M2 (serveur/adapter MCP)** | back | `infrastructure/src/orchestrator/mcp/` : serveur MCP exposant `idea_ask_agent`/`idea_launch_agent`/`idea_list_agents` (+ parité `idea_update_context`/`idea_create_skill`/`idea_stop_agent`) → `OrchestratorCommand` → `dispatch` → résultat inline. **Spike S-MCP** (crate, transport) isolé ici. | `infrastructure/src/orchestrator/mcp/` | mapping outil→commande ; `Arc<OrchestratorService>` injecté | unit (fakes + `OrchestratorService` à use cases fakes) : chaque outil mappe la bonne commande ; `idea_ask_agent` renvoie `reply` inline ; timeout → erreur typée, cible non tuée ; `idea_list_agents` liste ; JSON-RPC malformé → erreur, jamais panic. Hors-réseau (transport en mémoire/pipe scriptable). |
+| **M3 (câblage par projet)** | back | Démarrer le serveur MCP par projet ouvert dans `ensure_orchestrator_watch` (à côté du watcher) ; registre `mcp_servers` jumeau de `orchestrator_watchers` ; arrêt à la fermeture du projet. | `app-tauri/src/state.rs`, `commands.rs` | hook `ensure_orchestrator_watch` étendu | app-tauri : un serveur MCP par projet, idempotent ; fermeture du projet ⇒ arrêt ; coexiste avec le watcher fichier (les deux portes vivantes). |
+| **M4 (observabilité UI — optionnel)** | front | Surfacer dans l'UI Agents qu'une délégation est passée par MCP vs fichier (badge/source sur l'event `OrchestratorRequestProcessed` / `AgentReplied`). Non bloquant. | `frontend/src/features/agents` | DTO d'event enrichi (`source: "mcp"|"file"`) | Vitest : badge source affiché ; absence d'event ⇒ pas de régression. |
+
+**Ordre conseillé** : **M0 → M1 → M2 → M3** (→ M4 optionnel). M0 débloque tout (donnée pure) ;
+M1 injecte la conf (testable sans serveur) ; M2 livre l'adapter derrière un transport scriptable
+(spike confiné) ; M3 le câble par projet. M4 est du confort d'observabilité.
+
+---
+
+## 4. Conformité hexagonale & SOLID (rappel)
+
+- **Règle de dépendance** : `McpCapability`/`McpConfigStrategy` sont **domaine** (purs, validés).
+  Le serveur MCP, JSON-RPC, stdio/socket, le crate MCP sont **exclusivement** infra. Le domaine et
+  l'application **ignorent** MCP (l'application ne voit que `OrchestratorCommand`/`dispatch`).
+- **S** : le serveur MCP = une seule techno d'entrée (MCP→commande). `OrchestratorService` garde sa
+  responsabilité (commande→use cases). `LaunchAgent` gagne une étape d'injection homogène, pas une
+  responsabilité nouvelle.
+- **O** : ajouter une CLI MCP = un bloc `mcp` sur le profil (**donnée**). Aucun cœur touché.
+- **L** : les trois portes d'entrée (fichier, MCP, UI) sont substituables — même `dispatch`, même
+  résultat. Repli fichier ≡ MCP du point de vue de la réponse.
+- **I** : le serveur MCP ne reçoit que `Arc<OrchestratorService>` (pas les use cases en détail).
+- **D** : tout injecté au composition root (`state.rs`) ; aucun `new` d'adapter MCP ailleurs.
+
+---
+
+## 5. Chantiers adjacents (situés, NON cadrés ici)
+
+- **Hot-swap de l'AI profile** (chantier A, §15.1) : **LIVRÉ** (`ChangeAgentProfile`). Interaction
+  avec v3 : un swap vers/depuis un profil MCP change la surface (`mcp.is_some()`) ⇒ au relance,
+  `LaunchAgent` (ré)injecte ou retire la conf MCP automatiquement. **Rien à cadrer** : la surface suit
+  le profil courant, point de vérité unique.
+- **Reprise auto des sessions au redémarrage** (chantier B, §15.2) : **LIVRÉ** (`ListResumableAgents`,
+  `conversation_id` persisté sur la cellule). Interaction avec v3 : à la reprise, `LaunchAgent`
+  ré-matérialise la conf MCP comme à tout lancement (M1). **Rien à cadrer**.
+
+Ces deux chantiers **ne sont pas un prérequis** de v3/MCP et n'en bloquent aucun lot.
+
+---
+
+## 6. Synthèse des décisions
+
+1. **Capacité MCP = `Option<McpCapability>` sur le profil** (Open/Closed, `None` ⇒ repli fichier+prose, zéro régression sérialisation).
+2. **Retour synchrone d'`ask` : RIEN de neuf** — réutilise `send_blocking`/`AskAgent`/`AgentReplied`/`OrchestratorOutcome.reply` déjà livrés (§17). Pas d'outbox, pas de corrélation fichier, pas de `CorrelationId`. Le transport MCP corrèle nativement.
+3. **Interdiction subagents natifs conservée + alternative native** : prose adaptée selon surface ; conf MCP injectée **par CLI** au `LaunchAgent` dans le run dir isolé (`McpConfigStrategy` : ConfigFile/Flag/Env), symétrique au convention file et au seed permissions.
+4. **Frontières** : serveur MCP = **adapter entrant infra** (`infrastructure/src/orchestrator/mcp/`), pair du watcher fichier, appelant le **même** `OrchestratorService::dispatch`. **Aucun nouveau port** applicatif/domaine.
+5. **Lots** : M0 (capacité profil) → M1 (injection conf) → M2 (adapter/serveur MCP, spike confiné) → M3 (câblage par projet) → M4 (observabilité, optionnel).

.ideai/briefs/orchestration-v3-invocation-native.md

@@ -0,0 +1,85 @@
+# Brief Architecture — Orchestration v3 : invocation native d'agents (surface MCP + repli fichier)
+
+> Demandé par **Main** à **Architect**. Cadrage attendu **avant tout code** (méthode §3).
+> Ce brief ne prescrit pas l'implémentation : il pose le problème, les contraintes et les
+> décisions à trancher. À toi de produire la cartographie (ports, adapters, modèles, lots).
+
+## 1. Contexte & problème
+
+Aujourd'hui, un agent apprend qu'il doit déléguer via IdeA **uniquement par une instruction
+en prose** injectée en tête de son convention file (`compose_convention_file`,
+`crates/application/src/agent/lifecycle.rs` → bloc « # Orchestration IdeA »). Il écrit alors
+un JSON dans `.ideai/requests/<id>/*.json`, capté par l'`OrchestratorWatcher`
+(`crates/infrastructure/src/orchestrator/mod.rs`) → validé par le modèle domaine pur
+(`crates/domain/src/orchestrator.rs`) → exécuté par `OrchestratorService`.
+
+**Trois faiblesses constatées dans le code :**
+
+1. **Conscience = soft prompt.** Rien ne contraint l'agent ; rien ne l'empêche d'utiliser
+   le subagent natif du fournisseur ; le schéma JSON n'est même pas fourni dans l'instruction
+   (l'agent doit le deviner).
+2. **Pas de discussion inter-agents.** `agent.message` est marqué « future ». Le champ `task`
+   d'`agent.run` est replié dans `context`, mais `OrchestratorService` n'utilise `context`
+   que pour un agent **neuf** (initial `.md`) : pour un agent **déjà existant**, le `task` est
+   **silencieusement ignoré**. La réponse (`*.response.json`) ne porte qu'un ACK de cycle de
+   vie (`detail: "launched agent X"`), jamais la sortie produite par la cible.
+3. **Fire-and-forget.** Aucune corrélation requête↔réponse de contenu, aucun réveil du
+   demandeur.
+
+## 2. Objectif produit (vision Anthony)
+
+Rendre l'invocation d'un agent par un autre **aussi native que l'invocation de subagents dans
+Claude CLI** (l'outil `Task` : le modèle voit un outil typé, l'appelle, et **le résultat
+revient inline** dans sa conversation) — mais de façon **model-agnostic** (Claude, Codex,
+Gemini, custom) et **toujours médiée par IdeA** (qui garde identité, contexte, mémoire,
+observabilité UI).
+
+## 3. Direction pressentie (à valider/affiner par l'Architecte)
+
+**Exposer l'orchestration IdeA comme un serveur MCP** que IdeA branche sur chaque CLI qui le
+supporte (Claude Code, Codex, Gemini CLI supportent MCP). Outils pressentis :
+
+| Outil MCP | Effet |
+|---|---|
+| `idea_ask_agent(target, task) → reply` | Lance/réveille la cible, transmet la tâche, **attend et renvoie sa réponse** inline |
+| `idea_launch_agent(target, visibility)` | Lancement fire-and-forget (équiv. `agent.run` actuel) |
+| `idea_list_agents() → […]` | Découverte des agents du projet |
+
+Bénéfices : conscience native (l'outil apparaît dans la liste d'outils, plus de prose à
+« se rappeler »), arguments typés/validés (fini le JSON deviné), et surtout `ask_agent`
+**renvoie le contenu** → comble la messagerie inter-agents manquante.
+
+## 4. Points durs à trancher (cœur du cadrage)
+
+1. **Capacité par runtime.** Tous les profils ne supportent pas MCP/outils (custom CLI).
+   → Modèle **en couches** : surface MCP quand le profil le déclare ; **repli sur le protocole
+   fichier `.ideai/requests` + prose** sinon. Le port `AgentRuntime` gagne une capacité
+   déclarative (`supportsMcp` ou descripteur de capacités). Comment exprimer ça dans le profil
+   déclaratif (§9) sans casser l'existant ?
+2. **Retour synchrone d'`ask_agent`.** C'est le vrai défi : « attendre que la cible ait fini
+   son tour et capturer sa sortie » pour un fournisseur arbitraire = même problème que
+   l'inspecteur de session (cf. mémoire `conversation-resume-architecture`). Piste : la cible
+   écrit sa réponse dans un **outbox** `.ideai/`, l'outil MCP attend/poll avec corrélation
+   requête↔réponse + timeout. Définir : modèle de corrélation, event `AgentReplied`, sémantique
+   de timeout/erreur, et que faire si la cible tourne déjà (one-live-session-per-agent).
+3. **MCP vs subagents natifs.** On garde l'interdiction des subagents natifs (sinon
+   court-circuit d'IdeA = perte identité/mémoire/observabilité), mais on offre désormais une
+   **vraie alternative native**, pas qu'une interdiction. Comment configurer/injecter le serveur
+   MCP par CLI (chaque CLI a sa propre conf MCP) depuis le lancement IdeA ?
+4. **Frontières hexagonales.** Où vit le serveur MCP (nouvel adapter d'infrastructure ?), quel
+   port côté domaine/application, comment il réutilise `OrchestratorService` existant plutôt que
+   de le dupliquer.
+
+## 5. Chantiers adjacents (à seulement situer, pas à cadrer ici)
+
+Garder en tête la cohérence avec deux autres chantiers du même fil « agent = entité » :
+- **Hot-swap de l'AI profile** d'un agent existant (absent à toutes les couches aujourd'hui).
+- **Reprise auto des sessions au redémarrage** (terrain T5/T7 + `conversation_id` prêt mais
+  non câblé : rien ne relance les agents `agent_was_running` à l'ouverture du projet).
+
+## 6. Livrable attendu
+
+Une cartographie d'architecture pour l'**orchestration v3** : ports & adapters, modèle de
+messages (requête/réponse corrélées), capacité runtime MCP, stratégie de repli, découpage en
+**lots** testables (méthode §3), et la liste des décisions tranchées avec leur justification.
+Mets à jour `ARCHITECTURE.md` (§14.3) en conséquence.

.ideai/briefs/orchestration-v5-transport-bind-cadrage.md

@@ -0,0 +1,215 @@
+# Orchestration v5 — Bind transport S-MCP + fix registre session (cadrage)
+
+> **Agent Architecture.** Ce document tranche le **dernier kilomètre** de l'orchestration native : (1) le **bind transport** entre une CLI MCP réellement lancée et le serveur MCP par projet (verrou §S-MCP, resté ouvert depuis M3), et (2) le **fix de robustesse du registre de session** (mémoire `session-registry-agent-ambiguity`). Aucun code de production ici : décisions + contrats + découpage en lots testables.
+>
+> **État du terrain (lu, pas présumé)** :
+> - `infrastructure/src/orchestrator/mcp/{server,transport,jsonrpc,tools}.rs` : `McpServer::serve(&mut transport)` boucle ligne-à-ligne sur `Transport::{recv,send}` ; `StdioTransport<R,W>` (JSON Lines générique), `MemoryTransport` (tests). **`serve` n'est jamais appelé en prod.**
+> - `app-tauri/src/state.rs` : `ensure_mcp_server` crée un `McpServer` par projet et le **parke** sur un signal d'arrêt (`McpServerHandle::start` ⇒ `let _server = server; stop_rx.recv().await;`). **Aucun transport, aucun pair.**
+> - `application/src/agent/lifecycle.rs` : `apply_mcp_config` matérialise la conf MCP (`ConfigFile`/`Flag`/`Env`) dans le run dir isolé, **après** `apply_injection`, **avant** spawn/`factory.start`. `mcp_server_declaration` écrit un placeholder `{"command":"idea","args":["mcp-server"],"transport":"stdio|socket"}`.
+> - `application/src/terminal/registry.rs` : `TerminalSessions` (PTY) + `StructuredSessions` (IA) + agrégateur `LiveSessions`. Invariant **« 1 session vivante/agent »**.
+> - `application/src/error.rs` : `AppError::AgentAlreadyRunning { agent_id, node_id }` + code `AGENT_ALREADY_RUNNING` — **défini mais jamais levé** (le garde de `LaunchAgent` rebind/idempotent au lieu d'échouer).
+> - `app-tauri/src/commands.rs::list_live_agents` lit **seulement** `terminal_sessions.live_agents()` — **aveugle aux sessions structurées**.
+
+---
+
+## 0. Synthèse exécutive (décisions tranchées)
+
+1. **Transport S-MCP = `stdio-spawn`** : la CLI **spawn elle-même** un process serveur MCP fourni par IdeA. Ce sous-process est un **client de boucle de retour** (loopback) vers le process Tauri, pas un second `OrchestratorService`. Justification : c'est le **seul** modèle réellement supporté par Claude Code / Codex (déclaration `.mcp.json` `{command,args}`), **cross-OS sans port réseau** (compatible AppImage / Windows / SSH-remote), et il **résout le point dur** « comment le process serveur retrouve le bon projet » par **injection d'identité à l'`args`/`env`** au `LaunchAgent` (le projet est connu à ce moment-là). Le socket est **rejeté** comme défaut (ports/permissions/cross-OS) mais **gardé en TODO** derrière le même trait `Transport`.
+
+2. **Le binaire `idea mcp-server` est un sous-commande du binaire app-tauri existant** (pas un nouveau crate/binaire à distribuer séparément) : `main.rs` route `argv[1] == "mcp-server"` vers un mode **headless loopback** qui lit stdin/stdout (JSON Lines = `StdioTransport`) et **relaye** chaque message JSON-RPC au process IdeA principal via un **canal de loopback local** (Unix socket / Windows named pipe **par projet**, créé par `ensure_mcp_server`, chemin passé en `--endpoint`). Le `McpServer` (qui tient l'`OrchestratorService`) **vit dans le process Tauri** ; le sous-process `mcp-server` n'est qu'un **pont stdio↔loopback** ultraléger. Un seul binaire à livrer (AppImage/setup.exe).
+
+3. **Contrat conf↔serveur de bout en bout** rendu **cohérent** : `apply_mcp_config` (M1) écrit une déclaration qui pointe **exactement** vers ce que `ensure_mcp_server` (M3) a mis à l'écoute — `command = <exe IdeA>`, `args = ["mcp-server", "--endpoint", <loopback du projet>, "--project", <id>]`. Fin du placeholder.
+
+4. **Fix registre session = lot PRIORITAIRE et INDÉPENDANT du bind** (peut/doit partir en premier) : l'invariant correct est **« 1 session vivante par agent »** (décision produit verrouillée, mémoire `session-registry-agent-ambiguity` : un agent est un **singleton**, pas N instances). Le fix n'invente **pas** d'identité par cellule ; il **durcit l'invariant** sur les **deux** registres et **réconcilie les `layouts.json` à doublons**. Trois trous concrets à boucher (cf. §3).
+
+5. **Robustesse `ask`** : cible morte ⇒ lancement structuré puis envoi ; cible PTY brut ⇒ `Invalid` explicite (déjà fait) ; **cible occupée par un autre tour** ⇒ sérialisation **FIFO par agent** (nouveau, §4) ; timeout 300 s ⇒ cible **vivante**, erreur typée (déjà fait). Deux `ask` simultanés sur la même cible ⇒ file, **jamais** d'entrelacement de tours.
+
+6. **Frontières** : le pilotage de `serve` vit dans **l'adapter infra** (`McpServer` + une boucle **par connexion** sur le loopback du projet), supervisé par `McpServerHandle` (app-tauri) qui ne fait qu'**accepter les connexions** et spawn une tâche `serve` par pair. Aucune logique applicative ne fuit : le sous-process `mcp-server` ne connaît que des octets JSON-RPC ; `OrchestratorService` ignore tout du transport.
+
+---
+
+## 1. Décision 1 — Modèle de transport S-MCP
+
+### 1.1 Le point dur, posé proprement
+
+Une CLI MCP (Claude Code, Codex) attend une déclaration de serveur de forme **`{ "command": "...", "args": [...] }`** : à l'`initialize`, **elle spawn ce process** et parle **JSON-RPC sur son stdin/stdout**. Donc le « serveur » qu'elle voit est **un process enfant à elle**, distinct du process Tauri. C'est le cœur du problème : ce process enfant **n'a pas** l'`Arc<OrchestratorService>` du projet (use cases, registres de sessions, event bus vivent dans Tauri).
+
+Deux familles de solutions :
+
+| | **stdio-spawn (RETENU)** | socket (rejeté en défaut) |
+|---|---|---|
+| Ce que la CLI spawn | un **pont** `idea mcp-server` (stdio↔loopback) | rien — elle se connecte à un serveur déjà à l'écoute |
+| Où vit l'`OrchestratorService` | process Tauri (le pont relaie) | process Tauri (écoute directe) |
+| Cross-OS / AppImage | ✅ pipes stdio + loopback local (Unix socket / named pipe) | ⚠️ port TCP (firewall/permissions) ou socket — déclaration CLI variable |
+| Retrouver le bon projet | **`--endpoint`/`--project` à l'`args`**, fixés au `LaunchAgent` (projet connu) | l'adresse encode le projet, mais la CLI doit la connaître |
+| Compat Claude/Codex | ✅ `{command,args}` natif | ❓ support socket inégal selon CLI/version |
+| Cycle de vie | la CLI **possède** le pont (meurt avec elle) | serveur long-vécu, connexions multiplexées |
+
+### 1.2 Pourquoi stdio-spawn, malgré le sous-process en plus
+
+- **Compatibilité réelle** : `{command,args}` est le **dénominateur commun** des CLIs MCP. Le socket n'est pas universellement déclarable.
+- **Cross-OS sans port réseau** : le **loopback local** entre le pont et Tauri est un **Unix domain socket** (Linux/macOS) ou un **named pipe** (Windows) — déjà la techno la plus portable pour de l'IPC local, **sans firewall ni permission réseau**, donc **AppImage-safe** et **SSH-remote-safe** (le pont tourne côté machine de l'agent).
+- **Résolution du point dur par injection d'identité** : le projet est **connu** au moment du `LaunchAgent` (c'est lui qui écrit la conf MCP). On **encode** `--endpoint <chemin loopback du projet>` (+ `--project <id>` en garde-fou) dans les `args` de la déclaration. Le pont n'a **rien à deviner** : il se connecte à l'endpoint du **bon** projet. Le `McpServer` côté Tauri, lui, **est** déjà attaché à cet `OrchestratorService`/`Project` (créé par `ensure_mcp_server`).
+
+### 1.3 Le pont `idea mcp-server` (sous-commande du binaire existant)
+
+- **Pas de nouveau binaire distribué** : `main.rs` détecte `argv[1] == "mcp-server"` **avant** d'initialiser Tauri/WebKit, et bascule en **mode headless pont**. Un seul exécutable livré (AppImage / setup.exe).
+- **Rôle du pont** : `StdioTransport(stdin, stdout)` côté CLI ; un client de loopback côté Tauri. Boucle : lire une ligne JSON-RPC de la CLI → l'écrire sur le loopback → lire la réponse du loopback → l'écrire sur stdout. **Zéro logique métier** : c'est un tube transparent. (Optionnellement, le pont peut **directement** porter le `McpServer` si l'`OrchestratorService` était accessible — il ne l'est pas inter-process — d'où le relais.)
+- **Côté Tauri** : `ensure_mcp_server` crée **l'endpoint loopback du projet** (socket/pipe), et `McpServerHandle` **accepte** les connexions ; **chaque connexion** (= un pont = un agent) ⇒ une **tâche `McpServer::serve(&mut conn_transport)`** où `conn_transport` enveloppe le flux loopback. `McpServer` est **déjà** branché à l'`OrchestratorService` du projet.
+
+### 1.4 Identité de l'appelant (lève le `requester_id = "mcp"` figé)
+
+`server.rs::publish_processed` tague aujourd'hui `requester_id: "mcp"` (placeholder). Avec stdio-spawn, le pont **connaît l'agent** (le `LaunchAgent` peut injecter `--requester <agent-id>` dans les `args` de la déclaration, comme `--project`). Le pont passe cette identité dans la **poignée de connexion** (premier message de handshake loopback, hors JSON-RPC MCP), et `McpServer::serve` la porte dans son contexte de connexion ⇒ `OrchestratorRequestProcessed.requester_id` devient l'**agent réel**. Observabilité UI exacte (qui a délégué à qui).
+
+### 1.5 Socket = TODO derrière le même trait
+
+Le trait `Transport` (jsonrpc.rs) **isole** déjà le serveur du transport. Un `SocketTransport` (TCP/HTTP-stream) reste un **ajout sans toucher `McpServer`** si une CLI l'exige. Non requis pour Claude/Codex ⇒ **hors périmètre v5**, documenté.
+
+---
+
+## 2. Décision 2 — Contrat conf injectée (M1) ↔ serveur écouté (M3/v5)
+
+Bout en bout, **un seul chemin** :
+
+```
+profil.mcp = Some(McpCapability{ config: ConfigFile{".mcp.json"} | Flag{..} | Env{..}, transport })
+   │  (LaunchAgent, run dir isolé .ideai/run/<agent>/ ; après apply_injection, avant spawn)
+   ▼
+apply_mcp_config écrit la DÉCLARATION RÉELLE (fin du placeholder) :
+   {
+     "mcpServers": {
+       "idea": {
+         "command": "<chemin absolu de l'exe IdeA>",      ← std::env::current_exe()
+         "args": ["mcp-server",
+                  "--endpoint", "<loopback du projet>",     ← fourni par ensure_mcp_server
+                  "--project",  "<project id>",
+                  "--requester","<agent id>"]                ← identité (§1.4)
+       }
+     }
+   }
+   │  (la CLI lit .mcp.json à l'initialize)
+   ▼
+la CLI SPAWN  <exe IdeA> mcp-server --endpoint … --project … --requester …
+   │  (pont stdio↔loopback)
+   ▼
+le pont se connecte au LOOPBACK DU PROJET (créé par ensure_mcp_server)
+   │  (handshake : project id + requester id)
+   ▼
+McpServerHandle ACCEPTE ⇒ tâche McpServer::serve(conn)  [McpServer tient l'OrchestratorService du projet]
+   │  tools/call → map_tool_call → OrchestratorCommand → OrchestratorService::dispatch(&project, cmd)
+   ▼
+réponse inline (idea_ask_agent ⇒ outcome.reply) renvoyée verbatim à la CLI
+```
+
+**Invariant de cohérence à tester** : le **chemin de l'endpoint** et l'**exe** écrits par `apply_mcp_config` sont **exactement** ceux que `ensure_mcp_server` met à l'écoute pour ce projet. Source de vérité **unique** : une fonction (app-tauri) calcule l'endpoint d'un `ProjectId` ; M1 (qui écrit la conf) et M3/v5 (qui écoute) l'appellent tous deux. **Pas** de chaîne dupliquée.
+
+**Le `transport` du profil** reste surfacé dans la déclaration pour la voie socket future, mais en stdio-spawn il est **implicite** (la CLI spawn = stdio). `McpConfigStrategy` inchangé : `ConfigFile` écrit le fichier, `Flag`/`Env` passent le **chemin de la conf** (run dir) — sémantique déjà en place, on ne fait que **remplir** la déclaration de vrai contenu.
+
+---
+
+## 3. Décision 3 — Fix du registre de session (lot PRIORITAIRE, indépendant)
+
+### 3.1 Invariant correct (verrouillé)
+
+**1 session vivante par agent** (un agent = singleton : un `.md`, une conversation, un run dir, une mémoire). On **ne** modélise **pas** une identité par cellule. La **cellule est une vue** rebindable (§17.6). `session_for_agent` est donc **déterministe par construction** — à condition que l'invariant soit **réellement enforced** et que les **deux registres** soient considérés. Aujourd'hui il y a **trois fuites** :
+
+### 3.2 Trou A — le garde de `LaunchAgent` ne lève jamais `AgentAlreadyRunning`
+
+`LaunchAgent::execute` (lifecycle.rs ~877-920) : si l'agent a déjà une session vivante (PTY **ou** structurée) et qu'un `node_id` est demandé, il **rebind silencieusement** ; sans node, il **rend la session existante** (idempotent). C'est juste pour **réattacher une vue**, mais cela **masque** un vrai second lancement (deux cellules distinctes voulant le **lancer** chacune). `AppError::AgentAlreadyRunning` est **défini mais jamais levé**.
+
+**Décision** : distinguer **réattache de vue** (légitime, rebind) de **second lancement** (à refuser). Le signal de discrimination existe déjà dans le flux : un `LaunchAgentInput` issu d'une **réattache** (la cellule sait que l'agent tournait : `agent_was_running`/`conversation_id` présents) vs un **lancement neuf**. Le garde lève `AgentAlreadyRunning { agent_id, node_id_hôte }` quand un lancement **neuf** vise un agent **déjà vivant sur un autre node**, et **rebind** seulement quand le `node_id` demandé **est** le node hôte (ou réattache explicite). L'orchestrateur `spawn_agent` (`Visible{node_id}`) suit la **même** règle.
+
+### 3.3 Trou B — `list_live_agents` est aveugle aux sessions structurées
+
+`commands.rs::list_live_agents` ⇒ `state.terminal_sessions.live_agents()` **seulement**. Un agent **chat** (structuré) vivant n'apparaît **pas** ⇒ l'UI ne le désactive pas dans le dropdown ⇒ on peut tenter de le relancer ailleurs.
+
+**Décision** : la commande lit l'**agrégateur** `LiveSessions::live_agents()` (PTY **+** structuré), déjà présent dans le registre. Un seul point de vérité de liveness pour l'UI.
+
+### 3.4 Trou C — `layouts.json` à doublons (deux feuilles, même `agent`)
+
+Les layouts persistés **contiennent déjà** des feuilles en double sur le même `agent` id (constaté). À l'ouverture, **ne pas auto-lancer la 2ᵉ** ; **réconcilier** : une seule feuille reste « hôte vivant », les autres sont des vues mortes (pas de relance, pas de bannière fraîche). C'est précisément ce qui causait le **symptôme** (« une cellule reset au retour d'onglet »).
+
+**Décision** : étape de **réconciliation à l'ouverture du projet** (app-tauri, jumelle de `SnapshotRunningAgents`) : pour chaque agent apparaissant sur N feuilles, **garder une** hôte, **dé-flagger** `agent_was_running`/`conversation_id` sur les autres feuilles dupliquées. La reprise (B, §15.2) ne relance alors qu'**une** session/agent.
+
+### 3.5 Pourquoi indépendant du bind
+
+Aucun de ces trois trous ne touche MCP/transport : ils vivent dans `LaunchAgent`, `list_live_agents`, et l'ouverture de projet. Le fix **stabilise le routage de `ask`** (qui s'appuie sur `session_for_agent`) **avant** d'ouvrir la vanne MCP ⇒ on évite de débugger un `ask` mal routé **et** un transport neuf en même temps. **⇒ Lot R0, livré en premier.**
+
+---
+
+## 4. Décision 4 — Robustesse `ask` (sérialisation FIFO par agent)
+
+Sémantique cible (au-dessus de l'existant) :
+
+| Situation | Comportement |
+|---|---|
+| Cible inconnue | `AppError::NotFound` (fait) |
+| Cible morte | lancement structuré (background) puis envoi (fait) |
+| Cible vivante en **PTY brut** | `AppError::Invalid` explicite, jamais d'ACK trompeur (fait) |
+| Cible vivante structurée, **libre** | rendez-vous direct `send_blocking` (fait) |
+| Cible vivante structurée, **déjà en tour** (autre `ask`) | **file FIFO par agent** : le 2ᵉ `ask` attend son tour, **pas** d'entrelacement (NOUVEAU) |
+| Timeout 300 s | cible **vivante**, erreur typée `Timeout`, retry possible (fait) |
+
+**Le seul vrai manque = la concurrence.** Deux `ask` simultanés sur la même cible appelleraient `send_blocking` **en parallèle** sur la **même** `AgentSession` ⇒ deux tours entrelacés sur un moteur qui pilote **une** conversation. Inacceptable (cf. bug accents = writes non sérialisés).
+
+**Décision** : **sérialiser les tours par agent** dans `OrchestratorService::ask_agent` via un **verrou par `agent_id`** (un `Mutex`/sémaphore d'unité, registre `HashMap<AgentId, Arc<Mutex<()>>>` détenu par le service, ou porté par l'entrée de `StructuredSessions`). Un `ask` **acquiert** le verrou de l'agent avant `send_blocking`, le **relâche** après le `Final`/timeout. Les `ask` concurrents forment une **file naturelle** (ordre d'acquisition). Le timeout s'applique **au tour** (pas à l'attente du verrou) — ou un timeout global borné l'attente totale (décision : timeout **par tour** ; l'attente en file ne consomme pas le budget, mais un plafond d'attente évite l'inanition). Cohérent avec « 1 conversation déterministe/agent ».
+
+**Erreurs typées remontées aux deux portes** : MCP ⇒ `tool_result_text(.., isError=true)` (déjà) ; fichier ⇒ `*.response.json` avec le champ d'erreur (déjà via `OrchestratorOutcome`/watcher). Le verrou n'ajoute pas de nouveau type d'erreur ; un timeout d'attente en file ⇒ `Timeout` (même type).
+
+---
+
+## 5. Décision 5 — Frontières hexagonales (où vit `serve`)
+
+- **`McpServer::serve` = adapter infra**, piloté **par connexion** : `McpServerHandle` (app-tauri) **accepte** sur l'endpoint loopback du projet et, **par pair connecté** (= un agent), **spawn une tâche** `serve(conn)`. Le serveur reste **sans état de connexion** au-delà de l'identité du pair (portée par le contexte de connexion, §1.4).
+- **`McpServerHandle` évolue** : aujourd'hui il **parke** (`let _server; stop_rx.recv()`). Demain il **ouvre l'endpoint** + boucle d'`accept` ; à l'arrêt, ferme l'endpoint (les ponts enfants meurent avec leur CLI). **Toujours** non-bloquant pour open/close projet (l'`accept` est async, parqué sur l'absence de pair).
+- **Le sous-process `mcp-server`** vit dans `app-tauri` (route `main.rs`), mais ne connaît que **stdio + loopback + JSON brut** : **zéro** `OrchestratorService`, zéro use case. Frontière nette.
+- **Aucune fuite applicative dans l'infra** : `OrchestratorService::dispatch` est appelé **à l'identique** par les trois portes (fichier, MCP, UI). Le verrou par agent (§4) est une **règle applicative** ⇒ il vit dans `OrchestratorService` (ou le registre `StructuredSessions`), **pas** dans l'adapter MCP.
+
+---
+
+## 6. Découpage en LOTS testables (méthode §3)
+
+> Ordre global : **R0 (fix registre) d'abord** — indépendant, débloque la robustesse de `ask`. Puis **bind transport M5x**. Front (M5-UI) optionnel en fin.
+
+### Bloc R — Fix registre session (PRIORITAIRE, indépendant du transport)
+
+| Lot | Côté | Périmètre | Critères de test |
+|---|---|---|---|
+| **R0a** | back (application) | Garde `LaunchAgent` : lever `AgentAlreadyRunning{agent_id,node_hôte}` pour un **lancement neuf** ciblant un agent déjà vivant sur **un autre node** (PTY **ou** structuré) ; **rebind** seulement si node demandé = node hôte / réattache. Même règle dans `OrchestratorService::spawn_agent`. | lancement neuf d'un agent vivant ailleurs ⇒ `AgentAlreadyRunning` (code `AGENT_ALREADY_RUNNING`) ; réattache même node ⇒ rebind sans respawn ; idempotence background inchangée ; `ask` d'une cible morte ⇒ lancement OK (pas de faux positif). |
+| **R0b** | back (app-tauri) | `list_live_agents` lit `LiveSessions::live_agents()` (PTY **+** structuré). | un agent **chat** vivant apparaît dans la liste ; un agent PTY aussi ; aucun doublon ; sans session ⇒ vide. |
+| **R0c** | back (app-tauri) | Réconciliation à l'**ouverture projet** : pour un agent sur N feuilles, garder **une** hôte, dé-flagger `agent_was_running`/`conversation_id` sur les autres. | layout à doublons ⇒ après ouverture, **une seule** feuille « était en cours » pour l'agent ; layout sans doublon **inchangé** ; persistance idempotente (2ᵉ ouverture = no-op). |
+| **R0d** | front | Dropdown agent du leaf : désactiver/"déjà placé" via la liste R0b (PTY+chat) ; gérer le retour `AGENT_ALREADY_RUNNING` (aller-à / déplacer). | Vitest : agent vivant ailleurs ⇒ option désactivée + action « aller à la cellule » ; erreur backend mappée à un message clair. |
+
+### Bloc M5 — Bind transport S-MCP (stdio-spawn)
+
+| Lot | Côté | Périmètre | Critères de test |
+|---|---|---|---|
+| **M5a** | back (app-tauri) | **Endpoint loopback par projet** : fonction unique `mcp_endpoint(project_id)` (Unix socket / Windows named pipe) ; `ensure_mcp_server` l'ouvre, `stop_orchestrator_watch` le ferme. | endpoint créé à l'open, supprimé au close ; idempotent (1/projet) ; chemin déterministe par `ProjectId` ; pas de collision inter-projets. |
+| **M5b** | back (app-tauri) | **Sous-commande `mcp-server`** dans `main.rs` (avant init Tauri) : pont `StdioTransport(stdin,stdout)` ↔ loopback (`--endpoint`), handshake (`--project`,`--requester`). | `argv mcp-server` ⇒ mode headless, ne lance pas la webview ; relaie une requête JSON-RPC ligne→loopback→réponse→stdout ; EOF stdin ⇒ sortie propre ; endpoint absent ⇒ erreur non-zéro, jamais de hang. |
+| **M5c** | back (infra/app-tauri) | **`McpServerHandle` accepte** sur l'endpoint et **spawn `McpServer::serve(conn)` par pair** ; identité du pair (requester) portée au contexte de connexion ⇒ `OrchestratorRequestProcessed.requester_id` = agent réel (fin du `"mcp"` figé). | une connexion ⇒ une tâche serve ; `initialize`/`tools/list`/`tools/call` OK de bout en bout via le loopback (test d'intégration local, hors réseau) ; `requester_id` = l'agent ; déconnexion d'un pair n'affecte pas les autres ; arrêt ferme l'endpoint + termine les serve. |
+| **M5d** | back (application) | **`apply_mcp_config` écrit la déclaration RÉELLE** (fin placeholder) : `command = current_exe`, `args = ["mcp-server","--endpoint",mcp_endpoint(project),"--project",id,"--requester",agent]`. `ConfigFile` non-clobbering ; `Flag`/`Env` portent le chemin de conf. **Source d'endpoint partagée avec M5a.** | `mcp=None` ⇒ aucune écriture (inchangé) ; `ConfigFile` ⇒ `.mcp.json` pointe l'exe + endpoint **exacts** du projet ; endpoint identique à `ensure_mcp_server` (test de cohérence M1↔M3) ; non-clobbering. |
+| **M5e** | back (intégration) | **Smoke end-to-end loopback** (sans CLI réelle) : un faux pont écrit `tools/call idea_list_agents`/`idea_ask_agent` sur le loopback d'un projet et reçoit la réponse inline du `dispatch` réel. | `idea_list_agents` ⇒ JSON des agents ; `idea_ask_agent` vers une cible structurée ⇒ `reply` inline ; cible PTY ⇒ erreur typée ; JSON-RPC malformé ⇒ erreur, jamais panic ; **hors réseau**. |
+
+### Bloc A — Robustesse `ask` (concurrence)
+
+| Lot | Côté | Périmètre | Critères de test |
+|---|---|---|---|
+| **A0** | back (application) | **Sérialisation FIFO par agent** dans `ask_agent` : verrou par `agent_id` autour de `send_blocking` ; timeout **par tour** ; plafond d'attente en file. | deux `ask` concurrents sur la même cible ⇒ tours **séquentiels** (pas d'entrelacement), ordre FIFO ; un `ask` sur agent A et un sur agent B ⇒ **parallèles** ; timeout d'un tour laisse la cible vivante et **libère** la file ; plafond d'attente ⇒ `Timeout` typé. |
+
+### Optionnel
+
+| Lot | Côté | Périmètre | Critères de test |
+|---|---|---|---|
+| **M5-UI** | front | Badge **source** (`mcp`/`file`) + **requester réel** sur une délégation (réutilise `OrchestratorRequestProcessed`). | badge source correct ; requester = agent réel (plus « mcp ») ; pas de régression sans event. |
+
+**Ordre recommandé** : **R0a→R0b→R0c→R0d** (stabilise le routage), puis **A0** (concurrence `ask`, ne dépend pas du transport), puis **M5a→M5b→M5c→M5d→M5e** (bind), puis **M5-UI**. R0 et A0 sont livrables **sans** toucher MCP ; M5 ne doit partir qu'**après** R0 (sinon on débugge `ask` mal routé + transport neuf ensemble).
+
+---
+
+## 7. Conformité hexagonale & SOLID (rappel)
+
+- **Règle de dépendance** : JSON-RPC, stdio, loopback socket/pipe, sous-process `mcp-server` = **infra/app-tauri exclusivement**. `domain`/`application` ignorent MCP et le transport. Le verrou FIFO par agent est une **règle applicative** (vit dans `OrchestratorService`/registre), pas dans l'adapter.
+- **S** : `McpServer` = traduire JSON-RPC → `dispatch` ; le **pont** = relayer des octets ; `McpServerHandle` = cycle de vie + `accept` ; le verrou = sérialiser les tours. Aucune responsabilité fourre-tout.
+- **O** : un `SocketTransport` futur = un impl de `Transport` en plus, **zéro** modif de `McpServer`. Une CLI MCP de plus = un profil avec `mcp = Some(..)`, zéro code.
+- **L** : les trois portes (fichier, MCP, UI) sont substituables derrière `OrchestratorService::dispatch` — **un** comportement applicatif.
+- **I** : `McpServerHandle` ne voit que « accepter + servir » ; `OrchestratorService` ne voit que `dispatch` + registres ; l'UI ne voit que `LiveSessions::live_agents`.

.ideai/briefs/validation-reelle-inter-agents.md

@@ -0,0 +1,35 @@
+# Protocole — Validation réelle de la conversation inter-agents via IdeA
+
+> À exécuter depuis la **nouvelle AppImage** (build 2026-06-10 18:23, contenant R0+A0+M5,
+> commits `37e7274` / `6ca519b` / `cf89b3b`). L'ancienne image (testée avant) ne contenait
+> pas ce code et a renvoyé l'erreur attendue « agent Ask pas pilotable en mode structuré ».
+
+## But
+Prouver en conditions réelles qu'un agent (Main/Claude) peut **demander** une tâche à un autre
+agent (Ask/Codex) **via IdeA** et **recevoir sa réponse inline** — pas seulement par tests à fakes.
+
+## Pré-requis pour que le `ask` aboutisse
+- La cible (**Ask**) doit être pilotée en **mode structuré** (profil Codex avec adapter structuré).
+  Le menu de sélection d'agent ne propose normalement que des profils structurés (Claude/Codex).
+- Ask **ne doit pas** déjà tourner comme **terminal brut** (PTY) dans une cellule : sinon
+  `ask_agent` refuse (invariant « 1 session/agent », cible PTY brut = pas de canal de réponse).
+- Le plus simple : **laisser Ask éteint** et laisser `ask_agent` le **lancer lui-même** en
+  structuré (sémantique : cible morte ⇒ launch structuré background ⇒ send ⇒ Final).
+
+## Procédure (protocole fichier, identique au test précédent)
+1. Déposer `.ideai/requests/main/<nom>.json` :
+   ```json
+   { "type": "agent.message", "requestedBy": "Main", "targetAgent": "Ask",
+     "task": "Petite recherche, pas de code : résume en 3 points ce que fait le module
+              crates/infrastructure/src/orchestrator/mcp/ et liste les outils idea_*." }
+   ```
+2. Attendre l'apparition de `.ideai/requests/main/<nom>.json.response.json`.
+
+## Succès attendu
+`{ "ok": true, "action": "agent.message", "reply": "<réponse de Codex>" }` — le champ **`reply`**
+porte le contenu produit par Ask. (Échec précédent = `ok:false` + erreur PTY brut.)
+
+## Voie native MCP (bonus)
+Le bind transport S-MCP (M5) est livré : un agent lancé avec un profil MCP voit les outils
+`idea_*` (dont `idea_ask_agent`) et le résultat revient inline. À valider quand un profil MCP
+est branché sur Claude/Codex. Voir `.ideai/briefs/orchestration-v5-transport-bind-cadrage.md`.

.ideai/layouts.json

@@ -1,56 +0,0 @@
-{
-  "version": 1,
-  "activeId": "9188db80-8535-4786-a20b-3c9a36b222e3",
-  "layouts": [
-    {
-      "id": "9188db80-8535-4786-a20b-3c9a36b222e3",
-      "name": "Default",
-      "kind": "terminal",
-      "tree": {
-        "root": {
-          "type": "split",
-          "node": {
-            "id": "8aca2f93-1a9b-4693-9bba-9a01e130a48c",
-            "direction": "row",
-            "children": [
-              {
-                "node": {
-                  "type": "leaf",
-                  "node": {
-                    "id": "d8a86eb1-cd4d-4937-b900-4989da7c868d",
-                    "session": "8a976ad4-72d5-4dfa-9176-b0838e8e7e1d",
-                    "agent": "a6ced819-b893-4213-b003-9e9dc79b9641"
-                  }
-                },
-                "weight": 0.9225053
-              },
-              {
-                "node": {
-                  "type": "leaf",
-                  "node": {
-                    "id": "6c5be5e7-a54b-468c-a2e2-8ec853629d5e",
-                    "session": "b6ef5e09-411b-4da4-93a7-d32ecd4bb750"
-                  }
-                },
-                "weight": 1.0774947
-              }
-            ]
-          }
-        }
-      }
-    },
-    {
-      "id": "40ea4fa9-25b3-410b-9d3e-6350834b421b",
-      "name": "Git Graph",
-      "kind": "gitGraph",
-      "tree": {
-        "root": {
-          "type": "leaf",
-          "node": {
-            "id": "c840bfdd-3330-46a3-b727-0799f6853e72"
-          }
-        }
-      }
-    }
-  ]
-}

.ideai/memory/MEMORY.md

@@ -0,0 +1,67 @@
+# Memory Index
+
+- [agent-context-memory-and-profile-handoff](agent-context-memory-and-profile-handoff.md) — Decisions sur l'injection de contexte, la memoire durable, l'etat live et le handoff de profil entre agents IA.
+- [idea-product-directives-main-handoff](idea-product-directives-main-handoff.md) — Directives produit consolidees pour guider Main sur la robustesse, la persistance, le handoff cross-profile et la sobriete UX.
+- [remaining-work-idea-agent-control-ide](remaining-work-idea-agent-control-ide.md) — Etat des lieux des acquis et des chantiers restants pour aligner IdeA avec la cible d'IDE de controle d'agents IA.
+- [mcp-bridge-and-delegation-runtime-notes](mcp-bridge-and-delegation-runtime-notes.md) — Pieges runtime du pont MCP/delegation et regle de rebuild de l'AppImage (binaire qui tourne = AppImage, pas les sources).
+- [permissions-sandbox-system-state](permissions-sandbox-system-state.md) — Systeme de permissions/sandbox complet (Landlock sur PTY + structure) et le risque residuel $HOME/resume du chemin structure.
+- [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
+- [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.

.ideai/memory/agent-context-memory-and-profile-handoff.md

@@ -0,0 +1,106 @@
+---
+name: agent-context-memory-and-profile-handoff
+description: Decisions sur l'injection de contexte, la memoire durable, l'etat live et le handoff de profil entre agents IA.
+metadata:
+  type: project
+---
+# Agent Context, Memory, and Profile Handoff
+
+## Resume
+
+This note captures the current product direction for IdeA around agent context injection, project memory, live state, and profile handoff between AI providers.
+
+See also:
+
+- `idea-product-directives-main-handoff` for product priorities and UX constraints.
+- `remaining-work-idea-agent-control-ide` for the current implementation status and remaining work.
+
+## Context Injection
+
+- Agent context must be injected by IdeA at launch time; the model should not be expected to discover `AGENTS.md` or `CLAUDE.md` by itself.
+- The existing `contextInjection` architecture is the right mechanism, especially `conventionFile` for providers that support a conventional file in the run directory.
+- The current implementation is strongest for `conventionFile`; `flag`, `stdin`, and `env` do not yet receive the same fully-composed IdeA context.
+- The `flag` strategy appears fragile with the isolated run directory model because the relative path passed to the CLI may not resolve from the run directory.
+
+## Shared Project Context
+
+- `.ideai/CONTEXT.md` is intended as shared project context.
+- It is not created automatically; it only exists if something writes it.
+- It should carry active project constraints and contribution rules.
+- Example content for `CONTEXT.md`: architectural constraints, workflow rules, and operating conventions that every agent must apply immediately.
+
+## Durable Memory
+
+- `.ideai/memory/` is intended as durable, project-scoped memory shared by all agents of the same project.
+- It is not created automatically; it only exists once at least one memory note is saved.
+- The durable memory is a knowledge base, not a live activity log.
+- It should contain stabilised knowledge such as:
+  - architecture decisions
+  - feature summaries to implement later
+  - user preferences that persist across sessions
+  - important project facts and references
+- Durable memory should stay curated and low-noise.
+
+## Live State Versus Durable Memory
+
+- Durable memory should not be used as a shared real-time state feed for all agents.
+- IdeA should distinguish between:
+  - global context (`.ideai/CONTEXT.md`)
+  - durable memory (`.ideai/memory/`)
+  - live operational state (separate store)
+  - handoff summaries between sessions or profiles
+- Real-time work tracking, who-is-doing-what, and transient status should live in a dedicated state mechanism, not in durable memory.
+
+## Memory Consumption by Agents
+
+- The current launcher reads shared project context from `.ideai/CONTEXT.md` if present.
+- It also recalls project memory via `MemoryRecall` and injects a `# Memoire projet` section into the convention file.
+- This injection currently happens only for `conventionFile` profiles.
+- The recalled memory is shared at the project level, but each agent may receive a different subset depending on its persona and recall query.
+- Memory recall is computed at launch time and written into the generated context file.
+- There is currently no automatic live refresh when `.ideai/memory/` changes during an active session.
+
+## Recommendation for Live Memory Refresh
+
+- Automatic memory refresh could be useful, but it should be explicit and controlled.
+- If IdeA wants agents to benefit from memory changes while they are active, it should regenerate their effective context when needed instead of treating durable memory as a constantly streaming log.
+- For PTY agents, no automatic reread exists today.
+- For structured Claude/Codex sessions, each turn relaunches the CLI, but the generated convention file is not automatically rewritten when durable memory changes.
+
+## Profile Handoff and Session Continuity
+
+- A direct native session transfer from Claude to Codex is not the right mental model.
+- The correct model is continuity of work state, not native provider-session continuity.
+- IdeA should persist:
+  - a canonical conversation log
+  - a cumulative handoff summary
+  - the agent state
+  - the provider conversation id when useful
+- On provider swap, IdeA should launch the new profile with:
+  - regenerated project context
+  - regenerated durable memory recall
+  - the current agent persona
+  - a handoff summary plus recent transcript
+- The handoff summary should not be created only at the moment of swap.
+- IdeA should maintain summaries incrementally or at checkpoints so that a swap is still possible when the current provider is near a token or session limit.
+
+## Agent Ability To Write Durable Memory
+
+- Agents should be allowed to promote important knowledge into durable memory.
+- This should not rely on the agent guessing the capability.
+- IdeA should expose the capability explicitly through tools or commands and should inject a clear rule explaining when an agent may save durable knowledge.
+- This write ability should be constrained to stable, high-value information, not transient state.
+
+## Practical Classification Rule
+
+- Put immediate project rules and operating constraints in `.ideai/CONTEXT.md`.
+- Put stable, reusable project knowledge in `.ideai/memory/`.
+- Put current activity and coordination state in a separate live-state mechanism.
+- Put cross-session or cross-profile recovery material in a handoff/session layer.
+
+## Current Product Direction
+
+- Keep `CONTEXT.md` for project rules.
+- Keep `.ideai/memory/` for curated durable knowledge.
+- Introduce a separate live-state mechanism if agents must stay aligned on in-progress work.
+- Introduce persistent conversation logs and incremental handoff summaries to support profile swaps such as Claude to Codex.

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

@@ -0,0 +1,52 @@
+---
+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. Explique probablement les "builds qui ne produisent rien".
+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)
+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 complète (rappel, pas de beforeBuildCommand dans tauri.conf.json)
+1. `npm --prefix frontend run build` (produit `frontend/dist`).
+2. depuis `crates/app-tauri` : `NO_STRIP=true <cli tauri> build --bundles appimage`.
+   CLI tauri = `frontend/node_modules/.bin/tauri` (@tauri-apps/cli). Config = crates/app-tauri/tauri.conf.json.
+
+## Implication produit
+C'est très probablement la vraie cause des « builds AppImage qui ne produisent rien / attente
+sans résultat » signalés par l'utilisateur. À intégrer idéalement dans le flux de build d'IdeA
+(passer NO_STRIP quand on cible AppImage sur Arch, ou vendoriser un linuxdeploy récent).
+
+Lien : [[mcp-bridge-and-delegation-runtime-notes]],
+[[checkpoint-b2-bootstrap-applied-await-codex-reset-1430]].

.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/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-rotation-safety-design.md

@@ -0,0 +1,49 @@
+---
+name: conversation-rotation-safety-design
+description: memory note conversation-rotation-safety-design
+metadata:
+  type: project
+---
+---
+name: conversation-rotation-safety-design
+description: Cadrage initial pour la compression/rotation automatique non interruptive des conversations d'agents.
+metadata:
+  type: project
+---
+
+# Conversation Rotation Safety Design
+
+Objectif : reduire le cout token des conversations longues sans degrader la stabilite des agents ni les contacts inter-agents.
+
+Socle existant a reutiliser :
+- log canonique `.ideai/conversations/<conversationId>/log.jsonl` ;
+- `handoff.md` incremental ;
+- injection du handoff au lancement/relaunch ;
+- `LeafCell.conversation_id` = id logique IdeA de paire, distinct du resumable provider ;
+- `providers.json` pour `(pair_conversation_id, provider_key) -> engine_session_id` ;
+- `InputMediator.busy_state(agent)` et FIFO par agent ;
+- `ask_agent` avec lock de tour par agent + wait-for graph anti-deadlock ;
+- attach/detach cellule deja modelise : la cellule est une vue, `TerminalSessions::rebind_agent_node` existe ;
+- frontend write-portal sait deja compter la saisie humaine et declarer `set_front_attached`.
+
+Regle produit centrale : rotation automatique opportuniste, jamais interruptive. IdeA ne compacte/rote une session qu'a un point sur.
+
+Conditions minimales avant rotation :
+- agent `Idle` (`InputMediator.busy_state == Idle`) ;
+- aucune delegation/ticket/reply en cours ;
+- aucun contact entrant en cours, sinon queue ou ancienne session jusqu'a bascule ;
+- checkpoint durable OK : prompt/response appendes au log + `handoff.md` a jour ;
+- cellule stable : pas d'attach/detach ou changement de layout en cours ;
+- utilisateur non en train d'ecrire : focus/buffer non vide/frappe recente/IME composition/prompt interactif detectable ;
+- nouvelle session demarree detached/background et prete avant bascule ;
+- bascule atomique routing logique + attachement cellule ; ancienne session retiree ensuite.
+
+Etat cible conceptuel :
+`RotationRequested -> WaitForAgentIdle -> WaitForNoDelegation -> WaitForNoIncomingRoute -> WaitForCellStable -> WaitForUserInputClear -> Checkpointing -> StartReplacementDetached -> AttachReplacementToCell -> SwitchRouting -> RetireOldSession`.
+
+Premier lot recommande : fondation non destructive.
+- Ajouter modeles/policy de `ConversationRotation` et raisons de blocage.
+- Ajouter query/use case d'evaluation qui retourne `Ready` ou `Blocked(reasons)` sans tuer ni relancer.
+- Exposer les signaux manquants de cellule/saisie depuis le frontend vers backend, d'abord comme etat consultable.
+- Publier des events de statut de rotation uniquement informatifs.
+- Ne pas implementer la bascule physique avant que les tests de surete soient verts.

.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/feature-agent-skill-awareness-design.md

@@ -0,0 +1,50 @@
+---
+name: feature-agent-skill-awareness-design
+description: Design valide + decoupage de la feature « surfacer les skills assignes a un agent a la maniere MCP » (manifeste + idea_skill_read), a reprendre apres relance IdeA.
+metadata:
+  type: project
+---
+# Feature : skills connus de l'agent « a la MCP »
+
+Demarree le 2026-06-17. Branche Git **`feature/agent-skill-awareness`** (basee sur `develop` @ 8452333, qui contient deja le fix context-guard).
+
+## ETAT 2026-06-17 (apres-midi) : slice backend T1->T5 FAIT, VERT, COMMITTE.
+DevBackend a livre T1->T5, QA a couvert (23 tests, 1212 passed). Commits sur `feature/agent-skill-awareness` :
+- `ab34363` feat(skill-awareness): T1->T5 (manifeste # Skills disponibles + outil MCP idea_skill_read, description+effective_description, use case ReadSkill, cablage state.rs, dump legacy conserve en mode sans-MCP).
+- `1a10d67` fix(test): compteur d'outils MCP 11->12 (une 2e assertion codee en dur dans `crates/app-tauri/src/state.rs` ~l.2813 que QA avait ratee ; QA n'avait corrige que `infrastructure/tests/mcp_server.rs`).
+- `e93a2c1` = cherry-pick du fix cold-start (cf. Bug 8 dans [[mcp-bridge-and-delegation-runtime-notes]]) — present aussi sur la branche dediee.
+`cargo test --workspace` VERT sur l'arbre combine. **L'orchestrateur a committe lui-meme** (l'agent Git etait injoignable a cause du Bug 8) — A FAIRE RELIRE/REBASER PAR GIT une fois le canal restaure.
+
+**RESTE :** T6 (champ description dans creation/edition skill cote front) + T7 (e2e : rebuild AppImage avec le fix Bug 8, relance, agent neuf + skill assigne -> voit le manifeste + appelle idea_skill_read). Puis Git decide les merges (feature->develop ; fix cold-start->develop+main).
+
+## AJOUT 2026-06-17 (soir) : brief « capacites IdeA » INCONDITIONNEL — VERT, COMMITTE (566bff4)
+Besoin utilisateur elargi : un agent neuf ignorait TOUT le perimetre IdeA (pas que les skills). Cas vecu : « agremente le contexte du projet » -> l'agent reinvente son propre systeme de contexte car le bloc `# Orchestration IdeA` ne parlait QUE de delegation. Fix (GO Architect, meme fonction pure `compose_convention_file` lifecycle.rs, zero port/entite) : ajout d'un brief « capacites IdeA » TOUJOURS present (decrit la CAPACITE, jamais le contenu -> survit a memoire/contexte vides), dans les 2 surfaces, AVANT le persona :
+- mode MCP : nomme les outils contexte (`idea_context_read`/`idea_context_propose` avec semantique single-writer global HONNETE : proposition sans target = enregistree pour validation, PAS appliquee ; `idea_update_context` pour le .md d'un agent), memoire partagee (`idea_memory_read`/`idea_memory_write`), skills (`idea_skill_read`/`idea_create_skill`). Martele « le contexte projet d'IdeA EST le contexte, n'improvise jamais ton propre fichier ».
+- mode non-MCP : MEMES concepts via fichiers `.ideai/` UNIQUEMENT (CONTEXT.md, memory/+MEMORY.md, skills .md), AUCUN nom d'outil `idea_*` (cloisonnement strict des 2 surfaces — sinon casse `mcp_prose_*`/`non_mcp_prose_*`).
+QA : 5 tests dedies (brief inconditionnel des 3 capacites a zero contenu ; single-writer honnete ; non-MCP sans outil ; cloisonnement ; ordre avant persona). `cargo test -p application` = 0 failed (lib 52, agent_lifecycle 59). 1 assert existant adapte (`mcp_mode_without_skills_omits_section`). Commit atomique **566bff4** sur `feature/agent-skill-awareness` (Git a laisse les .ideai/ runtime hors commit). Merge feature->develop differe par Git jusqu'a T6+T7 (unite d'integration unique).
+
+## Historique
+Cycle initialement stoppe avant le code : la delegation MCP a wedge (Bug 7, puis Bug 8 residuel cf. [[mcp-bridge-and-delegation-runtime-notes]]).
+
+## Besoin
+Un agent neuf dans un projet neuf ignore les skills qui lui sont assignes (cas vecu : `build-appimage` assigne mais ignore, tout reinvente). Objectif : l'agent est **automatiquement au courant** de ses skills, comme il l'est des outils MCP, sans que l'utilisateur ait a le lui dire.
+
+## Decision produit (utilisateur, 2026-06-17) : approche « Manifeste + idea_skill_read »
+Diagnostic Architect : les skills sont DEJA injectes, mais (A) en VRAC (corps complet) en fin de `CLAUDE.md` -> lus comme de la doc, ignores ; (B) seulement au (re)lancement. On recadre « a la MCP » : affordances nommees+decrites en tete de contexte + chargement du corps a la demande.
+
+- Bloc **« # Skills disponibles »** injecte JUSTE APRES le bloc « # Orchestration IdeA » (haute altitude), listant `**<name>** — <description>` ; prose imperative + renvoi a `idea_skill_read(name=…)`. Omis si zero skill.
+- Nouvel outil MCP **`idea_skill_read(name)`** read-only, miroir exact de `idea_context_read`/`idea_memory_read` ; resout par nom (scope projet puis global), renvoie `content_md` inline ; erreur typee si introuvable/ambigu.
+- Champ **`description: Option<String>`** sur l'entite `Skill` + helper `effective_description()` (fallback : 1ere ligne non vide du `content_md`, nettoyee du `#`). `#[serde(default)]` sur l'index (retro-compat `index.json` legacy obligatoire).
+- Mode **sans MCP** (`profile.mcp` absent) : conserver l'ancien dump du corps complet (decision 4.2(b), zero regression).
+
+## Decoupage (commits atomiques par tache verte, decides par Git)
+- **T1 domaine** `crates/domain/src/skill.rs` : champ `description` + `effective_description()`.
+- **T2 store** `crates/infrastructure/src/store/skill.rs` (+ application/skill) : `description` dans IndexEntry (`serde(default)`), propage via `CreateSkill`.
+- **T3 convention-file** `crates/application/src/agent/lifecycle.rs` : section « # Skills disponibles » dans `compose_convention_file` (~l.2568, juste apres bloc Orchestration ~l.2586) ; alleger `resolve_skills` (~l.1202) pour n'utiliser que name+description (index, pas le corps) ; garder dump corps si non-MCP.
+- **T4 outil MCP** `crates/infrastructure/src/orchestrator/mcp/tools.rs` + commande `OrchestratorCommand::ReadSkill { name, requester }` + methode `read_skill` dans `OrchestratorService` + petit use case `ReadSkill` (compose le port `SkillStore` existant, AUCUN nouveau port).
+- **T5 cablage** `crates/app-tauri/src/state.rs` : injecter `ReadSkill` dans `OrchestratorService` (builder additif, comme le fix context-guard) + re-exports application (orchestrator/mod.rs + lib.rs).
+- **T6 front (differable)** `frontend` : champ description dans creation/edition de skill.
+- **T7 e2e** : rebuild AppImage + relance, agent neuf + skill assigne -> voit le manifeste + appelle `idea_skill_read`.
+
+## Pieges (Architect)
+Retro-compat `index.json` (serde default) ; resolution de nom ambigue (projet d'abord, erreur typee sinon) ; un skill assigne en cours de session reste invisible jusqu'au relaunch (limite inherente, comme MCP) ; pas de nouveau port, domaine = +1 champ, composition root seul point de cablage. GO Architect.

.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/git-owns-commit-merge-decisions.md

@@ -0,0 +1,12 @@
+---
+name: git-owns-commit-merge-decisions
+description: Ne jamais demander a l'utilisateur s'il faut committer/merger/brancher — c'est l'agent Git qui tranche toute la topologie du depot.
+metadata:
+  type: feedback
+---
+
+Je ne dois PLUS demander a l'utilisateur s'il faut committer, merger, OU gerer les branches (creer/checkout/switch/rebase/supprimer une branche, ni quoi, ni quand). TOUTE la gestion des branches et la topologie du depot est decidee par l'agent **Git** — c'est LUI qui tranche.
+
+**Why:** l'utilisateur a explicitement (CLAUDE.md §2.4 + confirme en session le 2026-06-17) defini Git comme garant du depot local : commits, merges, rebases ET toute la gestion de branches sont SA decision, pas celle de Main ni de l'utilisateur. Demander a l'utilisateur court-circuite ce role et le fait perdre du temps.
+
+**How to apply:** quand un lot est vert, je delegue a Git (`idea_ask_agent` target=Git) en lui livrant l'etat (fichiers, tests verts, etat de compilation) et c'est Git qui decide/execute commit, merge, ET la branche (creer une `feature/*`, switch, rebase, supprimer apres merge…). Avant de demarrer une nouvelle feature, je passe la main a Git pour la decision de branche. En cas de doute sur le versioning/branching, je demande a **Git**, jamais a l'utilisateur. Les actions SORTANTES (push/publication) restent la seule chose soumise a validation explicite de l'utilisateur. Voir [[session-limit-handling-design]].

.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-product-directives-main-handoff.md

@@ -0,0 +1,206 @@
+---
+name: idea-product-directives-main-handoff
+description: Directives produit consolidees pour guider Main sur la robustesse, la persistance, le handoff cross-profile et la sobriete UX.
+metadata:
+  type: project
+---
+# IdeA Product Directives For Main
+
+## Resume
+
+Cette note consolide les arbitrages produit explicites donnes par l'utilisateur pour aider `Main` a poursuivre le projet sans ambiguite.
+
+See also:
+
+- `agent-context-memory-and-profile-handoff` for the structural model of context, durable memory, live state, and handoff.
+- `remaining-work-idea-agent-control-ide` for the current implementation status and remaining work.
+
+Elle ne remplace pas les notes techniques existantes. Elle sert de reference prioritaire sur:
+
+- la robustesse attendue,
+- la persistance et la reprise,
+- le handoff entre profils IA,
+- la memoire projet partagee,
+- le live state projet,
+- la sobriete UX.
+
+## Priorite Absolue
+
+La priorite produit numero un est la robustesse.
+
+Ordre de priorite impose:
+
+1. robustesse et solidite avant tout
+2. persistance et reprise
+3. handoff cross-profile
+4. live state projet
+5. reste des features et du polish
+
+Regle de pilotage:
+
+- un systeme incomplet mais solide vaut mieux qu'un systeme riche mais fragile
+- `Main` doit privilegier les architectures et comportements qui reduisent les crashes, les incoherences d'etat et les flows difficiles a reprendre
+
+## Reprise Et Persistance
+
+Quand IdeA redemarre, l'objectif n'est pas seulement de rouvrir une UI ou de restaurer des handles techniques.
+
+La cible produit est:
+
+- qu'un agent sache compactement sur quoi il travaillait
+- qu'IdeA fournisse ce materiel de reprise automatiquement
+- que la reprise soit exploitable meme si la conversation visible precedente n'est pas restauree a l'identique
+
+Le bon modele est:
+
+- un log canonique IdeA comme source durable
+- un resume/handoff genere par IdeA comme couche compacte de reprise
+
+Le resume/handoff n'est pas un confort secondaire. Il fait partie du comportement normal du produit.
+
+## Handoff Cross-Profile
+
+La cible ideale est double:
+
+- reprendre correctement le travail
+- donner si possible une impression de continuite presque sans rupture
+
+Mais en cas de compromis, la priorite doit etre:
+
+- fidelite operationnelle du travail repris
+- avant la parfaite illusion de continuite terminale ou conversationnelle
+
+Autrement dit:
+
+- si un agent passe de Claude a Codex, IdeA doit d'abord garantir que Codex puisse reprendre le plus fidelement possible le travail utile
+- l'absence de restauration parfaite de l'ancien terminal est acceptable si le handoff reste bon
+
+## Perimetre Profils
+
+Le perimetre de reference immediat est:
+
+- Claude
+- Codex
+
+Toute fonctionnalite importante doit etre faisable pour ces deux profils.
+
+Directive associée:
+
+- reduire au maximum les dependances a des commandes, flags ou comportements specifiques a un profil
+- construire un noyau le plus generique possible tout en restant concretement compatible Claude/Codex
+- les autres profils pourront etre ajoutes plus tard si possible, mais ne doivent pas detourner le coeur du chantier actuel
+
+## Memoire Projet Partagee
+
+La memoire projet partagee doit rester petite, stable et utile.
+
+Elle ne doit pas devenir un gros bloc qui siphonne les tokens de l'utilisateur a chaque requete.
+
+Ce qu'un agent peut ecrire automatiquement dans la memoire partagee si c'est stable et utile:
+
+- decisions durables d'architecture ou d'organisation
+- preferences utilisateur durables
+- regles de workflow durables
+- references importantes a conserver
+- resumes de handoff utiles a la reprise inter-session ou inter-profil
+
+Ce qu'un agent ne doit pas y ecrire automatiquement:
+
+- conversations brutes
+- journaux detailles de travail
+- etats temporaires
+- files d'attente
+- coordination temps reel
+- essais/erreurs locaux
+- hypotheses non stabilisees
+- contenu redondant ou reconstructible ailleurs
+
+Principe de fond:
+
+- memoire durable = savoir stable
+- log canonique = historique
+- handoff = reprise compacte
+- live state = coordination vivante
+
+Ces couches doivent rester separees.
+
+## Live State Projet
+
+Le live state projet partage doit exister comme mecanisme interne d'IdeA.
+
+Contraintes produit:
+
+- il doit rester invisible pour l'utilisateur
+- il doit survivre au redemarrage d'IdeA
+
+Il ne doit pas se transformer en UI verbeuse ni en mecanisme demandant une intervention explicite de l'utilisateur.
+
+## UX Et Philosophie Produit
+
+IdeA doit etre tres facile d'utilisation.
+
+Objectif UX:
+
+- plug and play
+- pas de sensation de parametrage impose
+- pas de surcharge de tuto au premier lancement
+- pas d'impression que le produit force des comportements internes a l'utilisateur
+
+Ligne directrice souhaitee:
+
+- esprit "maniere Linux"
+- comportement simple et utile par defaut
+- pas de contrainte tant qu'il n'y a pas un vrai besoin
+- suggestion discrete seulement si IdeA detecte qu'une aide ou une optimisation devient utile
+
+Le precedent du compactage de contexte est considere comme la bonne direction:
+
+- pas de compactage impose d'emblee
+- une popup proposee seulement si IdeA sent un besoin
+
+## Transparence Des Mecanismes Internes
+
+Les mecanismes suivants doivent rester quasi invisibles pour l'utilisateur:
+
+- delegations inter-agents
+- FIFO
+- handoffs
+
+Ils peuvent devenir visibles en debug ou quand le produit a une bonne raison UX de les exposer, mais ils ne doivent pas etre ressentis comme une charge cognitive normale d'utilisation.
+
+## Frontiere Avec Le Chantier Inter-Agents De Main
+
+Les choix fins touchant la communication entre agents ne doivent pas etre recadres ici si `Main` est deja en train de les traiter.
+
+Cette note ne doit donc pas etre lue comme une specification d'implementation inter-agents detaillee.
+
+Elle fixe seulement les invariants produit suivants:
+
+- robustesse avant richesse fonctionnelle
+- reprise automatique par IdeA
+- log canonique + handoff genere par IdeA
+- support de reference pour Claude et Codex
+- memoire durable compacte et curatee
+- live state interne et persistant
+- UX discrete, simple et peu intrusive
+
+## Directive Finale Pour Main
+
+Si un arbitrage technique oppose:
+
+- elegance theorique
+- ou livraison rapide
+
+contre:
+
+- robustesse
+- reprise fiable
+- sobriete UX
+
+alors `Main` doit privilegier:
+
+- robustesse
+- reprise fiable
+- sobriete UX
+
+avant le reste.

.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/mcp-bridge-and-delegation-runtime-notes.md

@@ -0,0 +1,51 @@
+---
+name: mcp-bridge-and-delegation-runtime-notes
+description: Pieges runtime du pont MCP et de la delegation inter-agents IdeA, et la regle de rebuild de l'AppImage.
+metadata:
+  type: project
+---
+# Pont MCP & delegation : pieges runtime
+
+Deux bugs trouves le 2026-06-13 en testant la conversation inter-agents (`idea_ask_agent` vers TestConversation), tous deux corriges. Notes utiles pour ne pas reperdre du temps :
+
+## Le binaire qui tourne = AppImage installee, pas les sources
+L'IdeA en cours d'utilisation est `/home/anthony/Documents/IdeA_0.1.0_amd64.AppImage`. **Ce meme binaire sert a la fois de serveur orchestrateur (il tient `OrchestratorService`/`InputMediator` et compose les evenements) ET de binaire-pont** (`<exe> mcp-server …` declare dans chaque `.ideai/run/<id>/.mcp.json`). Donc **tout correctif cote serveur ou cote pont n'est actif dans l'app que apres rebuild + reinstall de l'AppImage et relance d'IdeA**. Un binaire `target/debug` fraichement compile ne valide que le pont (qui parle au serveur via le socket) ; il ne valide pas la composition cote serveur.
+**Comment appliquer :** apres une correction backend, rebuild AppImage (`npm --prefix frontend run build` puis, depuis `crates/app-tauri/`, `../../frontend/node_modules/.bin/tauri build --bundles appimage`), remplacer l'AppImage, relancer IdeA, puis retester. **Exclure NSIS** (`--bundles appimage`) sur Linux. **Piege FUSE (2026-06-14)** : l'etape finale `linuxdeploy` echoue avec `failed to run linuxdeploy` (linuxdeploy est une AppImage qui se monte via FUSE). Workaround obligatoire : prefixer `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1`. Le compile Rust reussit avant ce point ; seul le bundling casse, et l'`AppDir` est genere mais pas le `.AppImage`. L'artefact final = `target/release/bundle/appimage/IdeA_0.1.0_amd64.AppImage`.
+
+## Env AppImage pollue le shell
+La session shell herite des variables de l'AppImage montee (`APPDIR`, `LD_LIBRARY_PATH`, `PYTHONHOME` -> `/tmp/.mount_IdeA_*`). Consequences : `python3` casse (`No module named 'encodings'`) et lancer un binaire app-tauri fraichement compile tente de booter WebKit et crash. **Workaround :** lancer avec un env propre (`env -i PATH=/usr/bin:/bin HOME=$HOME XDG_RUNTIME_DIR=/run/user/1000 ...`), utiliser `jq` plutot que python.
+
+## Bug 1 — pont MCP en lockstep (corrige)
+`mcp_bridge.rs::relay` lisait 1 ligne client -> attendait 1 reponse loopback, en boucle. MCP n'est pas 1:1 : `notifications/initialized` n'a pas de reponse => deadlock juste apres `initialize`, et `tools/list` n'etait jamais relaye => les outils `idea_*` ne se chargeaient jamais (`claude mcp list` affichait quand meme "Connected" car `initialize` repond). Corrige en relay **full-duplex** (deux pompes concurrentes) + drain borne (`DRAIN_GRACE`) a la fermeture stdin. Symptome cote utilisateur : 3 jours de "outils MCP pas charges".
+
+## Bug 2 — prefixe de delegation perdu (corrige)
+Le signal `[IdeA · tâche de <demandeur> · ticket <id>]` qui dit a l'agent cible "reponds via `idea_reply`, jamais en texte" n'etait plus compose nulle part : supprime du backend (`service.rs` C3 §5.1) lors du passage de l'ecriture PTY au frontend, mais le frontend (`useWritePortal.ts`) ecrit `head.text` verbatim et ne l'ajoutait pas. La cible recevait la tache brute, repondait en texte => `idea_ask_agent` timeout. Corrige en composant le prefixe dans `infrastructure/src/input/mod.rs` (`delegation_preamble`) a l'emission de `DomainEvent::DelegationReady` ; la tache brute reste dans le `Ticket`/historique. Rappel : la correlation `idea_reply` marche par ticket OU par tete de FIFO (fallback), donc le ticket echo est recommande mais pas strictement requis.
+
+## Bug 3 — cold-launch race : 1er tour perdu (corrige 2026-06-14)
+Deleguer a un agent **froid** (pas encore lance) via `idea_ask_agent` echouait silencieusement : terminal cible vide, ask bloque jusqu'au timeout 300s ; un agent **chaud** (deja a son prompt, lance manuellement) marchait. Cause : avec `with_structured` non cable sur l'orchestrateur (regression assumee `aa2f67a`), tous les `ask` passent par le chemin PTY `ensure_live_pty` (`application/src/orchestrator/service.rs`). Un agent jamais vu etait initialise `Idle` (`BusyTracker::start_turn` -> `or_insert(Idle)`, `infrastructure/src/input/mod.rs`), donc le 1er `enqueue` publiait `DelegationReady` **immediatement** et ecrivait la tache dans le PTY avant que le CLI ait affiche son prompt -> tache perdue. Le prompt-ready watcher (lot C5) ne gardait que les tours suivants. Fix : `ensure_live_pty` renvoie un flag `cold_launch` ; si cold ET `prompt_ready_pattern` non vide, l'orchestrateur appelle `mark_starting(agent)` -> la `DelegationReady` du 1er tour est **differee** puis publiee par le watcher a l'apparition du prompt. Sans pattern ou agent chaud -> livraison immediate (zero regression). Touche `domain/src/input.rs` (port `mark_starting`), `infrastructure/src/input/mod.rs`, `service.rs`.
+
+## Bug 4 — le fix cold-launch ne s'armait jamais en prod (corrige 2026-06-15)
+Le « fix Bug 3 corrige 2026-06-14 » etait trop optimiste : il ne s'arme que si `gate_cold_start = cold_launch && prompt_ready_pattern non vide` (`service.rs`). Or le profil **Claude Code** (`664cc20c`, partage par TOUS les agents) dans `~/.local/share/app.idea.ide/profiles.json` n'a **aucun** `prompt_ready_pattern`. Donc `mark_starting` n'etait jamais appele -> `enqueue` publiait `DelegationReady` immediatement -> tache ecrite dans le PTY avant le prompt de `claude` -> 1er tour perdu -> `idea_ask_agent` vers un agent **froid** bloque jusqu'au timeout (un agent **chaud** marche). Le Bug 3 n'etait valide que par des tests unitaires qui injectent un pattern a la main : le gap d'integration (profil sans pattern) n'avait pas ete vu.
+**Fix (option B, signal MCP, sans sniff de prompt TUI) :** on gate le cold-launch des qu'un MCP est configure sur le profil (`gate_cold_start = cold_launch && (pattern non vide || profil.mcp.is_some())`), et on **libere** le tour differe quand le pont MCP de l'agent froid se connecte (= son CLI est up + outils charges) : nouveau port `InputMediator::release_cold_start(agent)` (drain du `deferred`, **sans** `mark_idle` car c'est un signal de DEMARRAGE, idempotent et OR-safe avec `prompt_ready`), `McpServer` fire un `ready_sink: Fn(&str)` sur `initialize` avec le `requester` du handshake, et la composition root (`state.rs::ensure_mcp_server`) parse le requester en `AgentId` -> `OrchestratorService::release_agent_cold_start`. Touche `domain/src/input.rs`, `infrastructure/src/input/mod.rs`, `infrastructure/src/orchestrator/mcp/server.rs`, `application/src/orchestrator/service.rs`, `app-tauri/src/state.rs`. Tests unitaires verts ; **validation live = rebuild AppImage + relance IdeA** (cf. section binaire qui tourne). Filet OR : si un jour un profil porte un `prompt_ready_pattern`, les deux signaux coexistent.
+**Methodo :** ne PAS deleguer la reparation du systeme inter-agents via le systeme inter-agents (casse) — utiliser les subagents natifs (outil Agent).
+
+## Bug 5 — la boucle `serve` du serveur MCP est en lockstep, un `ask` sans reponse wedge TOUTE la connexion (corrige 2026-06-15)
+Symptome : 1er `idea_ask_agent` vers un agent qui repond -> OK ; puis `ask` vers un agent qui ne rappelle JAMAIS `idea_reply` (ex. QA lance mais qui ne repond pas) -> ensuite **tout** appel suivant du MEME demandeur (meme `idea_list_agents`, sans rendezvous) se bloque. Cote utilisateur : "DevBackend ne marche plus" alors qu'il repondait 11s avant — en realite c'est la connexion du DEMANDEUR (Main) qui est morte, pas la cible. Annuler l'appel cote client ne deparke rien.
+Cause : `infrastructure/src/orchestrator/mcp/server.rs::serve` lisait 1 requete puis **awaitait `handle_raw` en entier** avant de relire. Pour `idea_ask_agent`, `handle_raw -> dispatch -> service.dispatch` attend le `idea_reply` de la cible : pendant cette attente la boucle ne relit plus rien -> pipeline de la connexion fige. C'est l'analogue COTE SERVEUR du Bug 1 (lockstep) qui n'avait ete corrige que cote pont (`mcp_bridge.rs`). NB : la couche application bornait deja le rendezvous (`service.rs::ask_agent` via `tokio::time::timeout`), donc l'attente n'etait pas infinie — le vrai coupable etait bien la serialisation de `serve`, pas l'absence de timeout.
+Fix : `serve` reecrite full-duplex non bloquante — `tokio::select!` entre `transport.recv()` et un canal `mpsc::unbounded::<Option<Vec<u8>>>` ; chaque message entrant traite dans une tache `tokio::spawn` qui possede un clone cheap `self.for_requester(self.requester.clone())` ('static) + un clone du `tx` ; reponses (`Some`) ou notifications (`None`) renvoyees par le canal et ecrites par la meme boucle ; arret gracieux via compteur `in_flight` (on draine les taches en vol apres EOF). Les reponses MCP portent l'`id` -> ordre indifferent. Le trait `Transport` (`&mut self` recv/send) et les signatures `serve`/`serve_as` restent intacts. + filet de securite : timeout serveur **isole au seul `idea_ask_agent`** (`ASK_RENDEZVOUS_TIMEOUT` 24h, finie ; setter `with_ask_rendezvous_timeout` `#[doc(hidden)]` pour les tests). Tests : `infrastructure/tests/mcp_server.rs` -> `pending_ask_does_not_wedge_the_connection_concurrent_call_still_answered` (anti-wedge, echoue sur l'ancien code) + `ask_agent_rendezvous_times_out_with_a_jsonrpc_error`. Verts : `cargo test -p infrastructure` (20 mcp_server), `cargo test -p app-tauri --lib mcp_e2e_loopback_tests` (6). **Validation live = rebuild AppImage + relance IdeA** (la connexion wedgee ne se deparke pas de l'interieur : il FAUT relancer IdeA). AppImage du 2026-06-15 10:58 contient le fix ; backup `~/Documents/IdeA_0.1.0_amd64.AppImage.old-prewedgefix`.
+Reste a investiguer (separe, non bloquant) : pourquoi QA lance ne repond pas du tout a une delegation (son `claude` n'appelle pas `idea_reply`) — impossible a creuser tant que la connexion du demandeur est wedgee ; le fix Bug 5 permet desormais de le diagnostiquer sans tout figer.
+
+## Bug 6 — la tache n'est JAMAIS ecrite dans le PTY d'un agent delegue en arriere-plan (corrige 2026-06-15)
+C'EST la cause racine du « reste a investiguer » du Bug 5. Symptome : un agent lance a la main (cellule visible, ex. DevBackend) repond ; un agent **froid auto-lance par `idea_ask_agent`** (ex. QA) ne repond JAMAIS → `ask` bloque jusqu'au timeout (24h, `ASK_AGENT_TIMEOUT`). Reproduction sure et non bloquante : `idea_stop_agent` puis `idea_launch_agent(task=…, visibility=background)`, et observer le dossier de session `claude` de la cible (`~/.claude/projects/<run-dir>/*.jsonl`) : **aucune nouvelle session** en 28 s = la tache n'a jamais ete soumise (le pont MCP de la cible, lui, se connecte bien).
+Cause : depuis ARCHITECTURE §20, l'**ecriture physique du PTV est faite par le write-portal FRONTEND** (`useWritePortal`), qui n'est monte **que pour une cellule de layout (leaf) visible**. Or `ensure_live_pty` cold-lance la cible en **background avec `node_id: None`** (`service.rs`) → aucune cellule montee → `useWritePortal` n'existe pas → l'event `DelegationReady` n'a **aucun consommateur** → tache perdue. Les fix Bug 3/4 (differer/liberer la `DelegationReady`) ne pouvaient donc jamais marcher pour un agent background : ils publient un event que personne n'ecoute cote UI.
+Fix (option « writer PTY backend ») : le mediateur ecrit lui-meme la tache dans le PTY **quand aucune cellule frontend n'est attachee**. Registre `front_owned` dans `MediatedInbox`, alimente par le front via `bindHandle`/`unbindHandle` → commande Tauri `set_front_attached` → `OrchestratorService::set_agent_front_attached` → `InputMediator::set_front_attached`. Point de livraison unique = `BusyTracker::publish_deferred` (chemin chaud immediat ET drains froids `prompt_ready`/`release_cold_start`), qui passe par un **HeadlessSink** optionnel cable par `MediatedInbox::with_pty`/`with_events` : agent dans `front_owned` ⇒ `Some(d)` (publie l'event, le front ecrit, inchange) ; sinon ⇒ ecrit texte puis (apres `submit_delay_ms`, defaut 60ms, anti-paste-detection) la `submit_sequence` dans le handle PTY bound, sur un `std::thread` detache (le watcher prompt-ready tourne sur un std::thread, PAS tokio — ne pas utiliser `tokio::spawn`). Touche `domain/src/input.rs` (port `set_front_attached`), `infrastructure/src/input/mod.rs` (HeadlessSink + front_owned + handles en `Arc<Mutex>`), `application/src/orchestrator/service.rs`, `app-tauri/src/{dto,commands,lib}.rs`, `frontend/src/{ports,adapters/input,adapters/mock,features/terminals/useWritePortal}`. Tests verts : `cargo test -p infrastructure` (input 34, dont `headless_agent_without_front_cell_is_written_by_the_backend` + `front_attached_agent_is_delivered_via_event_not_backend_write`), app-tauri lib 42, useWritePortal 9, tsc. **Validation live = rebuild AppImage + relance IdeA** (build 2026-06-15 11:42 ; backup `~/Documents/IdeA_0.1.0_amd64.AppImage.old-prefrontwriterfix`).
+NB diagnostic : `~/.claude/projects/<encoded-run-dir>/*.jsonl` = transcript de session `claude` de l'agent ; pas de nouveau fichier apres une delegation = tache jamais soumise. `ss -xp | grep idea-mcp` = ponts MCP connectes cote serveur.
+
+## Bug 7 — une delegation interrompue/annulee laisse la cible `Busy` a vie (corrige 2026-06-15, sources ; pas encore en AppImage)
+Symptome : un agent qui repondait (ex. DevFrontend a « 123x4=492 », QA pendant LP3) ne repond plus du tout aux delegations suivantes ; `idea_ask_agent` bloque jusqu'au timeout. DevBackend, lui, continue de marcher. Diagnostic ecarte 2 fausses pistes : (a) PAS le socket MCP — les 6 ponts sont ESTAB (`ss -xp | grep idea-mcp`), pont vivant ; (b) PAS « lance a la main vs par IdeA » — DevBackend est aussi auto-lance et marche. Le vrai discriminant : **une delegation vers cet agent a-t-elle ete interrompue/annulee cote demandeur ?** DevFrontend coince par l'interruption d'une tache LP3 ; QA coince par un ping diag rejete ; DevBackend jamais annule => OK. Confirmation cote transcript : la tache figure dans le `log.jsonl` de la conversation (donc enqueue cote serveur a eu lieu) mais PAS dans le transcript `claude` de la cible (`~/.claude/projects/<run-dir>/*.jsonl`) => jamais ecrite dans son PTY.
+Cause (lue dans `application/src/orchestrator/service.rs`, chemins `ask` PTY ~l.847-911 ET `ask_structured` ~l.927-1011) : l'agent passe `Idle→Busy` des `input.enqueue` (~l.978). Il ne redevient `Idle` que sur la branche **succes** (`input.mark_idle`, ~l.1001). Les branches **erreur/annulation/timeout** (~l.901-910 et ~l.1004-1009) appellent `mailbox.cancel_head` mais **jamais `mark_idle`**. Pire : quand le demandeur interrompt l'appel, le futur `ask_agent` est **dropped** => AUCUNE branche du `select!` ne s'execute => l'agent reste `Busy` pour toujours. Une cible `Busy` met les delegations suivantes en file derriere un tour fantome, jamais livrees au PTY. L'etat `Busy` vit en memoire dans le process serveur et **ne se deparke pas de l'interieur** : deblocage immediat = **relancer IdeA** (comme le wedge du Bug 5).
+Fix (corrige cote sources, `service.rs`) : garde RAII `BusyTurnGuard` (Arc clones de `InputMediator` + mailbox, `agent_id`, `ticket_id`, flag `armed`) cree juste apres l'enqueue dans les DEUX chemins (`ask` PTY et `ask_structured`) ; son `Drop` (si arme) appelle `cancel_head(agent,ticket)` puis `mark_idle(agent)` ; `disarm()` sur la branche succes (le `mark_idle` propre existant reste, pas de double cancel). Les `cancel_head` redondants des branches erreur/`_cancelled`/`_elapsed` ont ete retires au profit du garde (`cancel_head` est positionnel/idempotent). Indispensable que ce soit un garde et pas un `mark_idle` dans les branches : le cas reel est un futur DROPPED, aucune branche du `select!` ne s'execute. Tests verts : `cargo test --workspace` 80 suites 0 echec, dont `dropped_ask_future_frees_busy_target`, `second_delegation_delivered_after_dropped_ask`, `cancelled_ask_marks_target_idle` (tests/orchestrator_service.rs) + 2 tests du garde dans le `mod tests` de service.rs.
+VERDICT `sweep_stalled` (infra/input/mod.rs) : **purement advisory** — bascule `Alive→Stalled` et emet `AgentLivenessChanged` mais **n'appelle JAMAIS `mark_idle`** (par conception : « la FIFO et le tour continuent »). Ce n'est donc PAS un filet pour ce bug ; le garde RAII est la seule correction. Non recable (changement de semantique hors perimetre).
+**Pas encore actif live : rebuild AppImage requis** (`npm --prefix frontend run build` puis depuis `crates/app-tauri/` `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage`, remplacer l'AppImage, relancer IdeA). Le relancement d'IdeA debloque aussi DevFrontend/QA actuellement coinces `Busy` (etat en memoire). Methodo (rappel Bug 4) : NE PAS reparer le systeme inter-agent via `idea_ask_agent` (casse) — utiliser les subagents natifs (outil Agent).
+
+See also [[remaining-work-idea-agent-control-ide]], [[agent-context-memory-and-profile-handoff]].

.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/permissions-sandbox-system-state.md

@@ -0,0 +1,26 @@
+---
+name: permissions-sandbox-system-state
+description: Etat du systeme de permissions/sandbox IdeA (domaine pur -> projection advisory -> enforcement OS Landlock sur PTY ET structure) et l'unique risque residuel.
+metadata:
+  type: project
+---
+# Systeme de permissions / sandbox IdeA
+
+Chantier "permissions des agents" complet bout-en-bout au 2026-06-16, sur la branche `wip/p8c-checkpoint-before-codex`. Lots committes : LP4-0 (`b05d04a`), LP4-1/LP4-2 (`17ca65e`), LP4-3 (`7e01ac6`), LP4-4 (`6236cd7`).
+
+## Acquis (tout vert, ~80 suites)
+
+- **Domaine pur** (`crates/domain/src/permission.rs`, `sandbox.rs`) : modele declaratif (`Capability`, `Effect`, `Posture` Allow<Ask<Deny, deny-wins), `resolve()` (invariant produit : rien pose => `None` => CLI garde son prompting natif), `compile_sandbox_plan(eff, ctx) -> Option<SandboxPlan>`, port `SandboxEnforcer`, `render_permission_summary` (honnetete : fichiers = OS-enforced, commandes = advisory).
+- **Store** : `.ideai/permissions.json` (separe d'`agents.json` : securite projet, pas identite).
+- **Projection advisory LP3** : projecteurs Claude (`settings.json`) + Codex (sandbox/`config.toml`).
+- **Enforcement OS LP4** : `LandlockSandbox` (Linux) / `NoopSandbox` / `default_enforcer()`. Actif sur **les deux chemins** : PTY brut (`pty/mod.rs` `spawn_command_sandboxed`) ET structure Claude/Codex JSON (`session/process.rs` `run_turn_sandboxed`).
+
+## Technique d'enforcement (load-bearing, ne pas casser)
+
+`enforce(plan)` tourne sur un **thread jetable AVANT le spawn**, puis le child est spawne depuis ce thread => il herite le domaine Landlock via les credentials de la tache (garanti par le noyau a travers fork/clone/execve, y compris posix_spawn). **Pas de `pre_exec`** : `infrastructure` est `#![forbid(unsafe_code)]` (intact), et le pre_exec n'aurait ete qu'une assurance de determinisme, sans valeur de securite ; allouer dans `landlock` post-fork (pre_exec) serait au contraire dangereux (deadlock malloc en process multithreade). Fail-closed : `Err` d'enforce => aucun child. Le garde-fou anti-regression est le test e2e **"ecriture hors-grant bloquee"** (present pour PTY et structure) : tant qu'il est vert, l'heritage tient.
+
+## Risque residuel a traiter (signale par l'Architecte, NON couvert)
+
+Les CLI structurees (claude/codex = binaires Node) ont des besoins FS ambiants lourds : `~/.claude`/`~/.codex` (credentials + cache de session pour le **resume**), `node_modules`, libs systeme, caches temp. `compile_sandbox_plan` ne fence que les classes explicitement posees et garde les lectures ouvertes — mais une policy posant un `Deny`/posture restrictive touchant `$HOME` **peut casser le resume**. Le mecanisme est valide au fake CLI (zero token), mais **avant d'activer un plan restrictif en prod sur le chemin structure**, valider e2e manuellement qu'un vrai tour claude/codex sous plan representatif garde run_dir + home de la CLI atteignables. C'est un sujet de **composition du plan** (run_dir reachability ; `SandboxContext.run_dir` existe mais n'est pas encore consomme par la traduction pure), pas du mecanisme — lot suivant si besoin.
+
+Voir [[remaining-work-idea-agent-control-ide]] pour le reste des chantiers produit.

.ideai/memory/remaining-work-idea-agent-control-ide.md

@@ -0,0 +1,273 @@
+---
+name: remaining-work-idea-agent-control-ide
+description: Etat des lieux des acquis et des chantiers restants pour aligner IdeA avec la cible d'IDE de controle d'agents IA.
+metadata:
+  type: project
+---
+# Remaining Work For IdeA Agent Control IDE
+
+## Resume
+
+Cette note sert de point de reprise pour l'agent `Main`. Elle distingue ce qui est deja implemente, ce qui reste a stabiliser, et ce qui reste a construire pour que IdeA corresponde pleinement a la vision "patron + employes IA" avec memoire projet partagee, contexte partage, messagerie inter-agents transparente, FIFO par agent, et persistance de reprise.
+
+See also:
+
+- `idea-product-directives-main-handoff` for product priorities and UX constraints.
+- `agent-context-memory-and-profile-handoff` for the structural model separating context, durable memory, live state, and handoff.
+
+Etat observe le 2026-06-11 sur le depot local:
+
+- L'orchestration inter-agents synchrone est deja reelle cote application.
+- La FIFO par agent, la conversation par paire et `idea_reply` sont deja couvertes par des tests verts.
+- Le transport MCP natif par projet et le loopback sont testes verts localement.
+- La reprise de conversation cote session/layout est largement presente dans le code.
+- En revanche, plusieurs briques produit restent inachevees ou non consolidees de bout en bout.
+
+## Deja Livre Ou Tres Avance
+
+### 1. Artefacts projet dans `.ideai/`
+
+- Les agents projet sont persistes dans `.ideai/agents.json` et `.ideai/agents/*.md`.
+- Le contexte projet partage est modelise via `.ideai/CONTEXT.md`.
+- La memoire projet partagee est modelisee via `.ideai/memory/*.md` + `.ideai/memory/MEMORY.md`.
+- Les requetes d'orchestration fichier vivent sous `.ideai/requests/`.
+
+Conclusion: la direction "tout ce qui releve d'IdeA pour un projet doit vivre dans `.ideai/`" est deja la bonne direction architecturale. Il reste surtout a eliminer les ecarts pratiques et a consolider l'usage reel.
+
+### 2. Memoire projet partagee
+
+- `FsMemoryStore` et `MemoryRecall` existent.
+- Les agents peuvent recevoir un rappel de memoire projet a l'activation.
+- Le frontend et les use cases CRUD memoire existent deja.
+
+Conclusion: la memoire partagee du projet n'est plus un concept a inventer. Le travail restant est plutot sur la qualite du rappel, la curation, et l'usage continu pendant la vie des sessions.
+
+### 3. Contexte partage et contexte agent
+
+- Le contexte partage projet est separe du contexte agent.
+- Les contextes agent sont persistes sous `.ideai/agents/*.md`.
+- Le launcher injecte deja le contexte compose au demarrage.
+
+Conclusion: la separation `contexte projet` / `contexte agent` est en place.
+
+### 4. Messagerie inter-agents transparente
+
+- `AgentMailbox` + `InMemoryMailbox` existent.
+- `ConversationRegistry` + `InMemoryConversationRegistry` existent.
+- `OrchestratorService::ask_agent` et `reply` existent.
+- Les outils MCP `idea_ask_agent`, `idea_reply`, `idea_launch_agent`, `idea_list_agents`, `idea_stop_agent`, `idea_update_context`, `idea_create_skill` existent.
+- Les tests applicatifs passent sur FIFO, reponse synchrone, prevention de cycle, timeout, parallélisme entre cibles differentes.
+
+Verification locale du 2026-06-11:
+
+- `cargo test -p application --test orchestrator_service` : OK
+- `cargo test -p infrastructure --test mcp_server` : OK
+- `cargo test -p app-tauri --test orchestrator_wiring` : OK
+
+Conclusion: le coeur de la communication inter-agents n'est plus un chantier de conception. Il est deja implementé et teste.
+
+### 5. FIFO transparente quand un agent est occupe
+
+- La file d'entree par agent existe deja.
+- La serialisation des tours vers une meme cible existe.
+- Les `ask` concurrents vers des agents differents peuvent tourner en parallele.
+
+Conclusion: l'exigence "si l'utilisateur ou un autre agent parle a un agent deja occupe, la requete part en file FIFO de maniere transparente" est deja largement satisfaite au niveau coeur applicatif.
+
+### 6. Reprise de conversation et persistance de session
+
+- Les cellules/layouts persistent `conversation_id` et `agent_was_running`.
+- Les use cases de reprise (`ListResumableAgents`, popup de reprise, relance avec `conversation_id`) existent.
+- Les sessions structurees Claude/Codex savent porter un `conversation_id`.
+
+Conclusion: la persistance de reprise a deja une base concrete et substantielle.
+
+## Reste A Faire En Priorite
+
+### 1. Consolider la persistance "conversation continue" au niveau produit, pas seulement "resume technique"
+
+Le code sait deja reprendre une conversation via `conversation_id`, mais la cible produit demande plus qu'une simple reprise technique:
+
+- conserver une vraie continuite de conversation lisible pour l'utilisateur au redemarrage,
+- permettre au nouvel agent/profil de repartir avec l'etat utile,
+- rendre la reprise completement transparente dans l'UX.
+
+Reste donc a verrouiller:
+
+- la persistance canonique des conversations exploitable au niveau produit,
+- la strategie de resume/handoff quand on change de profil IA,
+- la coherence UX entre reprise de cellule, reprise de conversation, et reprise de travail.
+
+### 2. Implementer une couche persistante de handoff / resume cross-profile
+
+La memoire partagee existante dit explicitement qu'il faut persister:
+
+- un canonical conversation log,
+- un cumulative handoff summary,
+- l'etat agent,
+- les identifiants de conversation utiles par provider.
+
+Ce point n'apparait pas comme livre de bout en bout dans le depot actuel.
+
+Le besoin produit reste ouvert:
+
+- si un agent passe de Claude a Codex, IdeA doit reconstituer l'etat de travail sans dependre d'une session native transferable,
+- le handoff doit etre incremental, pas fabrique seulement au moment de la panne ou du swap.
+
+### 3. Introduire un vrai live-state partage au niveau projet
+
+La memoire durable ne doit pas servir de journal temps reel. La note memoire existante le dit deja.
+
+Il manque encore une couche explicite de "live operational state" pour:
+
+- qui travaille sur quoi,
+- tickets/intentions en cours,
+- etat d'avancement d'un agent,
+- derniere delegation utile,
+- elements transitoires de coordination inter-agents.
+
+Sans cette couche, une partie de la coordination reste soit volatile, soit repoussee dans des endroits qui ne sont pas faits pour ca.
+
+### 4. Verifier et finir l'integration MCP natif "IdeA-only" de bout en bout dans le flux reel de l'application
+
+Les tests locaux du transport MCP passent, ce qui place cette zone en fin de chantier plutot qu'au debut.
+
+Mais il reste a confirmer en situation reelle utilisateur:
+
+- qu'un agent lance par IdeA voit effectivement ses outils MCP sans action manuelle,
+- que les profils supportes utilisent bien cette voie par defaut,
+- que le fallback fichier+prose reste coherent quand MCP n'est pas disponible,
+- que l'observabilite UI des delegations et des replies est suffisamment claire.
+
+Point important: l'architecture historique qui mentionne encore un verrou M5 ouvert est probablement en retard par rapport au worktree local. Avant de planifier le prochain lot, `Main` doit revalider la documentation d'architecture a la lumiere du code/tests actuels.
+
+### 5. Stabiliser le registre de sessions et clarifier le modele singleton d'agent
+
+Le produit veut "1 agent = 1 employe". Cela impose une verite unique sur:
+
+- la session vivante de l'agent,
+- sa conversation courante,
+- sa cellule visible ou son execution en arriere-plan,
+- son etat occupé/libre/interrompu.
+
+Le code a deja beaucoup avance sur ce point, mais le worktree local montre encore un chantier actif autour de:
+
+- `application/src/terminal/registry.rs`
+- `application/src/orchestrator/service.rs`
+- `application/src/agent/lifecycle.rs`
+- `app-tauri/src/state.rs`
+
+Conclusion: ne pas considerer le sujet comme totalement clos tant que le worktree n'est pas nettoye et que la suite de tests ciblee n'est pas executee sur l'ensemble du flux concerne.
+
+### 6. Rendre la mise a jour de memoire/contexte vraiment automatique pendant la vie d'un agent
+
+La cible utilisateur dit qu'il ne doit jamais demander:
+
+- de charger une memoire,
+- de charger un contexte,
+- de mettre a jour la memoire,
+- de mettre a jour le contexte.
+
+Le lancement injecte deja beaucoup de choses automatiquement, mais il reste a verrouiller le comportement "pendant la vie" d'un agent:
+
+- quand regenerer le contexte effectif,
+- quand promouvoir une information stable vers la memoire durable,
+- comment distinguer signal utile et bruit,
+- comment eviter de compter sur des consignes manuelles a l'utilisateur.
+
+### 7. Unifier la conversation utilisateur <-> agent et agent <-> agent dans l'UX
+
+Le backend sait deja distinguer `User<->Agent` et `Agent<->Agent`.
+
+Le travail restant est surtout produit/frontend:
+
+- affichage clair des delegations et des retours,
+- visualisation non confuse des conversations par paire,
+- reprise lisible des threads,
+- transparence totale pour l'utilisateur final.
+
+Le diff local frontend suggere justement un remaniement en cours de la surface terminal/chat.
+
+### 8. Consolider la restriction et l'affordance des profils supportes
+
+Le modele actuel oriente fortement vers Claude/Codex structures, ce qui est coherent avec la fiabilite attendue.
+
+Reste a clarifier produit:
+
+- quels profils sont officiellement "employes IdeA" de premiere classe,
+- quel fallback proposer pour les profils non structures,
+- quelle UI montrer quand un profil ne supporte pas la delegation native fiable.
+
+### 9. Persistance conversationnelle globale de l'application
+
+La demande utilisateur mentionne explicitement qu'en relancant IdeA il faut retrouver la conversation.
+
+La reprise par `conversation_id` et layouts existe, mais il reste a confirmer ou completer:
+
+- la persistance lisible de l'historique conversationnel pour l'utilisateur,
+- la restauration des vues au redemarrage,
+- la coherence entre session technique, resume visuel et histoire de travail.
+
+Autrement dit: "reprendre une session moteur" n'est pas encore automatiquement equivalent a "retrouver sa conversation produit" dans tous les cas.
+
+## Chantiers Secondaires Mais Importants
+
+### 1. Mettre la documentation d'architecture a jour
+
+Le code local et les tests verts semblent avoir depasse certains passages de `ARCHITECTURE.md` et de briefs anciens.
+
+Il faut une passe de synchronisation documentaire pour eviter que `Main` suive un etat obsolete, en particulier sur:
+
+- statut reel du transport MCP,
+- statut reel de la FIFO inter-agents,
+- statut reel des conversations par paire,
+- ce qui reste vraiment ouvert entre handoff, live-state et UX.
+
+### 2. Curater le dossier `.ideai/`
+
+Le principe "tout ce qui est IdeA-projet va dans `.ideai/`" est bon, mais il faudra surveiller:
+
+- la proliferation de fichiers run/request/debug,
+- ce qui est durable vs derivable,
+- ce qui doit etre committe vs ignore.
+
+### 3. Formaliser les regles de promotion memoire
+
+Le systeme doit savoir quand enregistrer une connaissance stable sans polluer la memoire partagee.
+
+Il manque probablement encore:
+
+- une politique claire de promotion,
+- des heuristiques/outils explicites pour les agents,
+- des garde-fous contre la memoire bruit.
+
+## Worktree Local A Prendre En Compte
+
+Le depot local est actuellement dirty avec un chantier large non committe autour de:
+
+- orchestration MCP / loopback / serveur Tauri,
+- mailbox / conversations / session registry,
+- adaptation frontend terminal/chat/layout,
+- fichiers `.ideai/` du projet lui-meme.
+
+Consequence pour `Main`:
+
+- ne pas planifier a partir de `ARCHITECTURE.md` seulement,
+- d'abord relire le diff local,
+- ensuite reexecuter la suite de tests ciblee des zones touchees,
+- puis seulement decider si le prochain lot est "finition", "integration UI", ou "harden/persistence".
+
+## Ordre Recommande Pour La Suite
+
+1. Revalider et documenter l'etat reel du chantier MCP/orchestration a partir du code courant, puis remettre `ARCHITECTURE.md` a jour.
+2. Fermer proprement le sujet "1 agent = 1 session vivante coherente" en nettoyant le registre/session lifecycle encore en mouvement.
+3. Concevoir puis implementer une vraie couche de live-state partage projet.
+4. Concevoir puis implementer la couche persistante de handoff/canonical conversation log cross-session et cross-profile.
+5. Finir l'integration UX/frontend pour que toute cette orchestration reste invisible et naturelle pour l'utilisateur final.
+
+## Synthese Courte
+
+Le plus gros changement de perception pour `Main` est le suivant:
+
+- IdeA n'est plus au stade "il faut inventer la delegation inter-agents".
+- IdeA est plutot au stade "le coeur de delegation existe deja; il faut maintenant le consolider, le documenter, le rendre pleinement persistant, et le rendre transparent dans l'UX".

.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/session-limit-handling-design.md

@@ -0,0 +1,38 @@
+---
+name: session-limit-handling-design
+description: Design valide pour la detection des limites de session des agents et la reprise auto a la levee.
+metadata:
+  type: project
+---
+
+Feature : detecter quand un agent IA est en limite de session (et jusqu'a quelle heure), puis reprendre ou il en etait une fois la limite levee. Cadree le 2026-06-16.
+
+Constat dur : l'heure exacte de reset n'existe nulle part de facon universelle (ni OS, ni code de sortie, ni API inter-modeles) — elle est fabriquee par le fournisseur et seulement exposee dans le flux de sa CLI. Donc « 100% fiable + zero dependance modele + heure exacte » sont incompatibles simultanement ; on vise le meilleur compromis via un detecteur hierarchique.
+
+Solution retenue — detecteur hierarchique calque sur la hierarchie de readiness existante ([[remaining-work-idea-agent-control-ide]]) :
+- Niveau 1 (solide) : l'adapter structure extrait limite + reset du flux machine. Pour Claude, `rate_limit_event.rate_limit_info` est DEJA parse dans `infrastructure/session/claude.rs` mais jete (reduit a Heartbeat) — il suffit de lire `resetsAt`.
+- Niveau 2 (configurable) : champ de profil `rate_limit_pattern` (regex + capture heure) pour agents PTY/TUI sans adapter structure, dans la lignee des profils declaratifs §9.
+- Niveau 3 (filet humain) : si rien ne matche mais agent `Stalled` (deja prevu dans `domain/readiness.rs`), IdeA DEMANDE a l'utilisateur. Garantit le « 100% meme pour un novice » : jamais d'inaction silencieuse.
+
+Model-agnostic tenu AU DOMAINE : le domaine ne connait que `RateLimited { until: Option<Instant> }`. Le savoir specifique modele est confine aux adapters/profils (philosophie §9).
+
+Reprise = partie facile et deja model-agnostique : pivot sur `conversation_id` du moteur + `--resume` natif (deja cable dans `session/claude.rs` + `agent/resume.rs`) qui portent tout l'historique. Pas de reconstruction manuelle fragile.
+
+Decisions produit verrouillees (2026-06-16) :
+- Reprise : AUTOMATIQUE a l'heure de reset, ANNULABLE (fenetre + notification).
+- Couverture : les TROIS niveaux d'emblee (incl. repli regex niveau 2).
+- Etat : EN MEMOIRE uniquement (pas de persistance de SessionLimit). Consequence assumee : le reveil auto ne joue que tant qu'IdeA reste ouvert ; si l'IDE est ferme/rouvert apres le reset, le chemin existant `ListResumableAgents` (agent_was_running/conversation_id) prend le relais.
+
+Decoupage (cycle dev/test §3) : 1) domaine (variante `ReplyEvent::RateLimited`, `ReadinessSignal::RateLimited`, etat `SessionLimit`) ; 2) adapter Claude (extraire resetsAt) ; 3) profil (`rate_limit_pattern`) ; 4) application (planificateur de reprise sur le port Clock) ; 5) UI (badge « limite jusqu'a HH:MM » + filet humain).
+
+Avancement (committe sur `feature/agent-session-limits`) :
+- LS1 domaine, LS2 adapter Claude niveau 1, LS3 port Scheduler + TokioScheduler, LS4 service application + reconciliation T4 : DONE.
+- LS5 (98bfcf4) detecteur niveau 2 declaratif `RateLimitParser` (regex confinee infra) + module `timeparse` pur partage niveau 1/2 (epoch s/ms, RFC3339, heure murale avec passage de minuit) : DONE, 221 tests infra verts.
+- LS6 (ea94e75) cablage : 5 variantes `DomainEvent` (AgentRateLimited/ResumeScheduled/ResumeCancelled/Resumed/RateLimitSuspected) + `ReplyEvent::RateLimited` relayees en `DomainEventDto` (events.rs) ; `chunk_from_event` traite RateLimited -> None (non terminal, comme Heartbeat) : DONE, workspace vert.
+- LS7-backend (9df5923) cablage app-tauri : `LaunchAgentOutput.profile` expose (lifecycle.rs), `StructuredSessions::meta_for_session` (registry.rs, lookup N1), `ResumeContext`/`AppAgentResumer` (impl port `AgentResumer` au-dessus de LaunchAgent) + instanciation/drain du `SessionLimitService` (TokioScheduler) dans `AppState::build` (state.rs), taps N1 (agent_send) & N2 (launch_agent, parser regex confine) + commande `cancel_resume` (commands.rs/lib.rs), dep `async-trait`. 2 tests d'integration (session_limit_wiring.rs) verts, suites app-tauri+application vertes. Git : reste sur feature/agent-session-limits, PAS de merge develop avant LS7-front.
+- LS7-front (4fad042) : 5 variantes au union `DomainEvent` (src/domain/index.ts) ; etat `limitByAgent` dans useAgents (patron `delegationSourceByRequester`) ; `AgentLimitBadge.tsx` (badge « limite jusqu'a HH:MM » + compte a rebours + bouton « Annuler la reprise » -> port `InputGateway.cancelResume` -> commande `cancel_resume`) ; cable dans AgentsPanel. 24 tests front. Champs wire reels = suffixe Ms : `resetsAtMs`/`fireAtMs` (PAS `resetsAt`/`fireAt`).
+- LS8 (filet humain niveau 3, decision Architect = B « demander = armer, pas juste informer ») :
+  - backend (c480d28) : `SessionLimitService::confirm_human_resume(agent, node, conv, resets_at_ms)` (source `Human`, refactor privé `arm_scheduled` partagé avec `on_rate_limited`, reutilise branche Scheduled, annulable, AUCUN evenement nouveau) ; commande `set_resume_at(agent_id, resets_at_ms)` (resout node_id via `node_for_agent` + conv best-effort, NOT_FOUND si pas de cellule vivante). 15+4 tests (clamp passe, dedup croise, parite auto/humain).
+  - front (5d9dd32) : `InputGateway.setResumeAt` -> `set_resume_at` ; formulaire de saisie d'heure sur l'etat suspected-sans-heure (helper pur `timeInputToEpochMs`) -> arme la reprise -> badge bascule auto via `agentResumeScheduled`. TODO LS7 retire.
+  - fix hygiene (3f3504e) : compteur gateways mock 13->14 (`permission`).
+- STATUT : FEATURE TERMINEE, 3 niveaux complets, tout vert (Rust domain/application/app-tauri + front agents/adapters 109 tests). MERGEE --no-ff dans `develop` (merge d7041c5, 0 conflit). Branche `feature/agent-session-limits` conservee (non supprimee). Etat = EN MEMOIRE uniquement (pas de persistance SessionLimit, cf. decision verrouillee). Aucun push (develop local en avance sur origin ; action sortante en attente de validation).

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

@@ -0,0 +1,192 @@
+{
+  "version": 1,
+  "projectDefaults": {
+    "rules": [
+      {
+        "capability": "read",
+        "effect": "allow",
+        "paths": [
+          "**"
+        ],
+        "commands": []
+      },
+      {
+        "capability": "write",
+        "effect": "allow",
+        "paths": [
+          "**"
+        ],
+        "commands": []
+      },
+      {
+        "capability": "delete",
+        "effect": "allow",
+        "paths": [
+          "**"
+        ],
+        "commands": []
+      },
+      {
+        "capability": "executeBash",
+        "effect": "allow",
+        "paths": [],
+        "commands": []
+      }
+    ],
+    "fallback": "allow"
+  },
+  "agents": [
+    {
+      "agentId": "a6ced819-b893-4213-b003-9e9dc79b9641",
+      "permissions": {
+        "rules": [
+          {
+            "capability": "read",
+            "effect": "allow",
+            "paths": [
+              "**"
+            ],
+            "commands": []
+          },
+          {
+            "capability": "write",
+            "effect": "deny",
+            "paths": [
+              "**"
+            ],
+            "commands": []
+          },
+          {
+            "capability": "delete",
+            "effect": "allow",
+            "paths": [
+              "**"
+            ],
+            "commands": []
+          },
+          {
+            "capability": "executeBash",
+            "effect": "allow",
+            "paths": [],
+            "commands": []
+          }
+        ],
+        "fallback": "allow"
+      }
+    },
+    {
+      "agentId": "dce19c75-9669-4e45-b8de-9950025157da",
+      "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": "cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5",
+      "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": "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"
+      }
+    }
+  ]
+}

.ideai/skills/index.json

@@ -0,0 +1,17 @@
+{
+  "version": 1,
+  "skills": [
+    {
+      "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/a72dac60-641c-4417-b0d7-94b8539f817a.md

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