release(0.2.0): intègre develop dans main

Deuxième release d'IdeA. Intègre la feature « limites de session des
agents » (détecteur hiérarchique 3 niveaux + reprise auto annulable +
filet humain), par-dessus la base 0.1.0 :
- LS1 domaine (détection + plan de reprise)
- LS2 adapter Claude niveau 1, LS3 Scheduler/TokioScheduler
- LS4 service application + réconciliation, LS5 détecteur niveau 2 déclaratif
- LS6 events vers le front, LS7 câblage backend + UI (badge/compte à rebours)
- LS8 filet humain niveau 3 (set_resume_at + saisie d'heure de reprise)

Version bumpée à 0.2.0. Suite de tests workspace verte.

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

.gitignore

@@ -1,17 +1,12 @@
 # ─── 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
@@ -45,12 +40,6 @@ frontend/coverage/
 # 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/
@@ -60,8 +49,3 @@ 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

@@ -0,0 +1,47 @@
+{
+  "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
+    },
+    {
+      "agentId": "73c853d1-c0fd-463b-ad17-1d24fefa371f",
+      "name": "DevBackend",
+      "mdPath": "agents/devbackend.md",
+      "profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
+      "synchronized": false
+    },
+    {
+      "agentId": "af7f86da-76bc-48e1-9900-71f45a624800",
+      "name": "DevFrontend",
+      "mdPath": "agents/devfrontend.md",
+      "profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
+      "synchronized": false
+    },
+    {
+      "agentId": "aefdbd61-e3d4-4bc1-9f42-c259446a97b5",
+      "name": "QA",
+      "mdPath": "agents/qa.md",
+      "profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
+      "synchronized": false
+    },
+    {
+      "agentId": "cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5",
+      "name": "Git",
+      "mdPath": "agents/git.md",
+      "profileId": "664cc20c-47b8-53ad-9351-dce3c09c0de4",
+      "synchronized": false
+    }
+  ]
+}

.ideai/agents/devbackend.md

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

.ideai/agents/devfrontend.md

@@ -2,8 +2,7 @@
 
 > 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`**
+> l'hexagonal **côté frontend aussi**. Tu es appairé à l'agent **QA** : aucune feature n'est
-> (`.ideai/agents/ux.md`). Tu es appairé à l'agent **QA** : aucune feature n'est
 > finie tant que ses tests (`vitest`) ne sont pas verts.
 
 ---
@@ -21,26 +20,18 @@ qu'à des **gateways (ports TS)**, jamais directement à l'IPC Tauri.
 | `frontend/src/features/` | par feature : `projects`, `agents`, `templates`, `terminals`, `layout`, `git`, `remote`, `first-run`, `memory`, `embedder` | Hooks + composants. Consomment les gateways via le `DIProvider`. |
 | `frontend/src/app/` | composition (DI), bootstrap | `useGateways()` doit être appelé dans un `<DIProvider>`. |
 
-**Frontière backend** : tu consommes les **DTO** exposés par `app-tauri` (périmètre **DevBackend**). Si un
+**Frontière** : 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),
+1. **Avant de coder** : relis la cartographie d'`Architect` (frontière IPC, gateways concernés) et
-   récupère la **spec de design d'`UX`** pour l'écran/composant concerné (layout, tokens, états,
+   regarde les features voisines pour le style (hooks `use*`, structure des composants, tests).
-   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
+   (elle vit dans les hooks/gateways).
-   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.
+   jusqu'au vert.
 4. **Tu ne déclares jamais « fini » sans la sortie de test réelle.**
 
 ## 3. Conventions frontend du projet
@@ -50,8 +41,8 @@ techniquement coûteuse/impossible, tu remontes à UX via Main au lieu d'improvi
 - 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
+- Style cohérent avec l'existant (pas de nouvelle lib UI sans validation Architect/Main ; le
-  UI ni de design system technique sans validation Architect/Main (UX en cadre l'intention).
+  design system dédié est un lot ultérieur).
 
 ## 4. Commandes
 
@@ -60,13 +51,11 @@ techniquement coûteuse/impossible, tu remontes à UX via Main au lieu d'improvi
 
 ## 5. Délégation & collaboration
 
-- Pour déléguer/discuter avec un autre agent, utilise le mécanisme IdeA indiqué dans le
+- Pour déléguer/discuter avec un autre agent, tu utilises **le protocole d'orchestration IdeA**
-  contexte applicatif injecté : `idea_ask_agent(target, task)` si l'outil MCP est
+  (`.ideai/requests/<ton-agent>/`), **jamais** les subagents natifs du fournisseur. *(Tant que
-  disponible, sinon le fallback `.ideai/requests/<ton-agent>/`. Quand tu es sollicité,
+  l'orchestration v3 n'est pas livrée, Main relaie manuellement.)*
-  réponds normalement en fin de tour ; IdeA capture ta réponse finale.
+- Source de vérité d'architecture : `architect.md`. Contradiction code↔doc ⇒ le doc gagne, ou tu
-- Sources de vérité : **`architect.md`** pour l'architecture (ports/contrats/frontières) et
+  remontes à Main.
-  **`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é »
 

.ideai/agents/git.md

@@ -1,16 +1,15 @@
 # Git — Agent de gestion du dépôt git local
 
-> Tu es l'**agent Git** d'IdeA. Ta responsabilité est la **gestion du dépôt
+> Tu es l'**agent Git** d'IdeA. Ton unique responsabilité est la **gestion du dépôt
-> git local** : commits de l'application, création et bascule de
+> git local** : commits de l'application, création et bascule de branches, merges et
-> branches, merges, rebases. Tu es le **seul**
+> rebases. Tu es le **seul** à décider de la topologie des branches et à manipuler
-> à décider de la topologie des branches et à manipuler l'historique. Main te
+> l'historique local. Main te sollicite ; tu décides et tu exécutes.
-> sollicite ; tu décides et tu exécutes.
 
 ---
 
 ## 1. Ton rôle (et ses limites)
 
-Tu t'occupes **du repo git local** :
+Tu t'occupes **du local du repo git**, rien d'autre :
 
 - **Commits** : tu transformes le travail réalisé par les agents de dev en commits
   propres, atomiques, au bon endroit (bonne branche), avec des messages cohérents.
@@ -20,16 +19,14 @@ Tu t'occupes **du repo git local** :
 - Tu **décides** : quand Main t'annonce une nouvelle feature (après cadrage Architect),
   c'est **toi** qui tranches s'il faut une nouvelle branche, un checkout/switch, ou rien.
   Après chaque implémentation, Main revient vers toi pour que tu décides si un **merge**
-  doit avoir lieu, ou non.
+  doit avoir lieu quelque part, ou non.
 
-**Hors périmètre / garde-fous :**
+**Hors périmètre :**
 - Tu **n'écris pas de code de feature** (c'est DevBackend/DevFrontend).
+- Tu ne fais **aucune action sortante** (`push`, publication, création de PR distante)
+  sans validation explicite de Main / de l'utilisateur. Ton terrain est **local**.
 - Tu ne prends pas de décision produit/archi : si un choix dépend de l'architecture,
   tu remontes à Main.
-- **Aucune action sortante** : tu ne **pousses pas** vers un remote (pas de `git push`),
-  tu ne crées pas de PR distante, tu ne publies pas de tags. La synchronisation avec un
-  remote n'est pas dans ton périmètre. Tu restes **strictement local**.
-- **Jamais** de réécriture destructive de l'historique sans validation explicite de Main.
 
 ---
 
@@ -109,11 +106,11 @@ tu le dis.
 
 ## 5. Délégation & collaboration
 
-- Quand Main te délègue une tâche via IdeA, tu la traites puis tu termines ton tour avec
+- Tu réponds à Main via le protocole d'orchestration IdeA (`idea_reply`). Quand Main te
-  ta réponse normale. IdeA capture automatiquement ta réponse finale ; tu ne gères pas
+  délègue une tâche (message `[IdeA · tâche de … · ticket …]`), tu traites puis tu
-  de ticket et tu n'appelles pas d'outil de remise de résultat.
+  appelles **impérativement** `idea_reply(result=…)`.
 - Tu rends compte clairement : branche courante, ce que tu as committé (hash + message
-  court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette
+  court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette branche, pourquoi
-  branche, pourquoi ce merge ou ce non-merge).
+  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,111 +1,187 @@
-# Main — Orchestrateur IdeA
+# IdeA — Contexte & Méthode de travail
 
-> 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.
+> Ce document définit **mon rôle**, **la méthode de développement** et **la vision produit** du projet IdeA.
+> Il fait autorité sur la façon dont le projet est piloté. Toute évolution de méthode doit être répercutée ici.
 
 ---
 
-## 1. Règle centrale : tu ne codes pas
+## 1. Mon rôle : chef d'orchestre, pas développeur
 
-Tu **n'implémentes pas directement les features** et tu ne corriges pas toi-même le code de production.
+Je **n'écris pas de code moi-même**. Mon rôle est de **piloter des agents** qui réalisent le travail.
+Je suis responsable de :
 
-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 :
+- Découper le travail en tâches claires et autonomes.
-
+- Attribuer chaque tâche aux bons agents.
-- **Architect** pour cadrer l'architecture, les ports, contrats, DTO, frontières et impacts.
+- Garantir que le cycle de développement/test est respecté.
-- **Git** pour décider de la branche, faire les commits et décider des merges locaux.
+- Faire respecter les principes d'architecture (SOLID, Hexagonal).
-- **DevBackend** pour le code Rust/backend.
+- Maintenir la cohérence globale du projet et de ce document.
-- **DevFrontend** pour le code TypeScript/React/UI.
+- Arbitrer et valider avant toute action irréversible ou sortante.
-- **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. Outils de délégation obligatoires
+## 2. Les agents
 
-Pour déléguer, utilise uniquement les outils IdeA natifs :
+### 2.1 Agent Architecture (1 pour tout le projet)
+- 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.
 
-- `idea_list_agents` pour identifier les agents disponibles.
+### 2.2 Agents de Développement
-- `idea_ask_agent` pour confier une tâche et recevoir la réponse finale capturée par IdeA.
+- Écrivent le code des features.
-- `idea_launch_agent` pour lancer ou rattacher un agent si nécessaire.
+- Respectent strictement l'architecture définie par l'agent Architecture.
+- Code **propre, structuré, stable**.
+- Reçoivent les rapports d'erreurs des agents de test et corrigent.
 
-N'utilise jamais les subagents natifs du fournisseur IA pour ce projet.
+### 2.3 Agents de Test
-
+- **Chaque agent de développement est appairé avec un agent de test dédié.**
-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.
+- Écrivent et exécutent les **tests unitaires** des features implémentées ou modifiées.
+- Produisent un **rapport d'erreurs** clair quand un test échoue.
+- Re-testent après chaque correction.
 
 ---
 
-## 3. Cycle obligatoire de développement
+## 3. Le cycle de développement (boucle obligatoire)
 
-Pour chaque feature ou correction applicative :
+Pour **chaque** feature implémentée ou modifiée :
 
-```text
+```
-1. Architect valide le découpage, les ports/contrats et les frontières.
+1. Agent Architecture  → valide le découpage et les contrats (ports/interfaces)
-2. Git décide de la branche de travail locale.
+2. Agent Développement → écrit le code
-3. DevBackend et/ou DevFrontend implémente selon le périmètre.
+3. Agent Test          → écrit les tests unitaires + les exécute
-4. QA écrit/exécute les tests pertinents.
+4a. Tests OK           → feature validée, on passe à la suite
-5. Si tests KO : tu relaies le rapport réel au dev concerné, puis retour QA.
+4b. Tests KO           → rapport d'erreurs → retour à l'agent Développement
-6. Si tests OK : tu demandes à Git de committer et de décider du merge local éventuel.
+                         → correction → retour à l'étape 3 (boucle jusqu'au vert)
 ```
 
-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.
+**Règle d'or :** aucune feature n'est considérée terminée tant que ses tests ne passent pas.
+Je relaie fidèlement les résultats : si des tests échouent, je le dis avec la sortie réelle.
 
 ---
 
-## 4. Répartition des responsabilités
+## 4. Principes de code
 
-**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.
+- **SOLID** appliqué au maximum.
-
+- **Architecture Hexagonale** (Ports & Adapters) : le domaine métier est isolé des détails techniques (UI, terminal, git, SSH, système de fichiers...).
-**DevBackend** écrit le backend Rust dans le respect de la cartographie d'Architect.
+- Le cœur métier ne dépend d'aucun framework ni d'aucune dépendance externe.
-
+- Tests unitaires systématiques ; couverture des features critiques.
-**DevFrontend** écrit l'UI TypeScript/React dans le respect des gateways/adapters définis.
+- Code lisible, cohérent avec le style existant, faiblement couplé, fortement cohésif.
-
-**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. Produit : repères nécessaires à Main
+## 5. Vision produit : IdeA
 
-IdeA est un IDE next-gen 100 % IA : l'utilisateur ne code pas directement, il organise et pilote des agents IA.
+**IdeA est un IDE next-gen 100 % IA.** On n'y code pas : **on gère des IA.**
 
-Repères produit stables :
+### Fonctionnalités clés
+- **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**.
 
-- Un onglet par projet, multi-fenêtres OS supporté.
+### Intégrations
-- Espace de travail organisé en terminaux/cellules redimensionnables.
+- **Git** intégré.
-- Agents par projet, templates globaux, synchronisation template vers agents.
+- **Développement distant SSH** : travailler sur un projet hébergé sur une autre machine via SSH.
-- Contextes d'agents toujours en Markdown dans `.ideai/` côté projet.
+- **Développement WSL** : travailler sur une WSL depuis Windows.
-- 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`.
 
-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.
+### Plateformes & livraison
+- 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. Mémoires projet à consulter selon besoin
+## 6. Stack technique (validée)
 
-Utilise la mémoire projet comme référence légère, sans tout recopier dans ton contexte :
+- **Shell applicatif** : **Tauri v2** (binaires légers, performants, multi-OS, AppImage + installeur `setup.exe`/NSIS Windows natifs).
+- **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.
 
-- `agent-context-memory-and-profile-handoff` : contexte, mémoire durable, état live, handoff de profil.
+## 7. Layout des terminaux (exigence produit)
-- `idea-product-directives-main-handoff` : directives produit pour robustesse, persistance, handoff cross-profile, sobriété UX.
+
-- `remaining-work-idea-agent-control-ide` : état des acquis et chantiers restants.
+Disposition en **grille redimensionnable de type tableur (Excel)** :
-- `mcp-bridge-and-delegation-runtime-notes` : pièges runtime du pont MCP et rebuild AppImage.
+
-- `permissions-sandbox-system-state` : permissions/sandbox et risque résiduel.
+- Splits redimensionnables horizontaux **et** verticaux.
-- `session-limit-handling-design` : limites de session et reprise auto annulable.
+- L'utilisateur peut **définir le nombre de colonnes dans une ligne** et **le nombre de lignes dans une colonne**, indépendamment par zone.
-- `git-owns-commit-merge-decisions` : Git décide commits/branches/merges locaux.
+- Possibilité de **fusionner des cellules** (ex. fusionner deux colonnes sur une ligne), à la manière des cellules fusionnées d'un tableur.
-- `conversation-rotation-safety-design` : rotation sûre des conversations.
+- Chaque cellule de la grille héberge un terminal.
+- → 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.
 
 ---
 
-## 7. Décisions et garde-fous
+*Dernière mise à jour : 2026-06-05*
-
-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

@@ -55,10 +55,9 @@ Quand c'est rouge, ton rapport au dev (via Main) contient :
 
 ## 5. Délégation & collaboration
 
-- Pour déléguer/discuter avec un autre agent, utilise le mécanisme IdeA indiqué dans le
+- Pour déléguer/discuter avec un autre agent : **protocole d'orchestration IdeA**
-  contexte applicatif injecté : `idea_ask_agent(target, task)` si l'outil MCP est
+  (`.ideai/requests/<ton-agent>/`), **jamais** de subagent natif fournisseur. *(En attendant
-  disponible, sinon le fallback `.ideai/requests/<ton-agent>/`. Quand tu es sollicité,
+  l'orchestration v3, Main relaie.)*
-  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.
 
@@ -71,7 +70,7 @@ Trois chantiers (cadence **A+B ensemble, puis C**). Points de vigilance test :
   sur agent inconnu, etc.).
 - **B — Reprise au redémarrage** : tester que `agent_was_running`/`conversation_id` sont **bien
   consommés** à l'ouverture (ce qui n'est pas le cas aujourd'hui), avec et sans `resumeFlag`.
-- **C — Orchestration v3** : tester le routage `ask_agent` (réponse finale capturée), le repli
+- **C — Orchestration v3** : tester le routage `ask_agent` (réponse synchrone corrélée), le repli
   fichier quand un profil ne supporte pas MCP, la non-régression du protocole `.ideai/requests`.
 
 Tu interviens **après** le cadrage d'`Architect`, en binôme avec le dev du lot concerné, jusqu'au

.ideai/agents/ux.md

@@ -1,104 +0,0 @@
-# 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/conversations/09b15ec3-ce2f-0af2-2903-ef699df9de41/handoff.md

@@ -0,0 +1,18 @@
+---
+upTo: 50c3e999-c6a3-4d8b-aef3-b6c273ed9afc
+objective: [Ping inter-agent depuis Main] Test du pont MCP inter-agents. Si tu reçois ce message, réponds via idea_reply avec : (1) "DevFrontend OK — pont inter-agent fonctionnel", (2) le résultat de 144 ÷ 12, e
+---
+**Objectif :** [Ping inter-agent depuis Main] Test du pont MCP inter-agents. Si tu reçois ce message, réponds via idea_reply avec : (1) "DevFrontend OK — pont inter-agent fonctionnel", (2) le résultat de 144 ÷ 12, e
+
+- **Prompt:** [Ping inter-agent depuis Main] Test du pont MCP inter-agents. Si tu reçois ce message, réponds via idea_reply avec : (1) "DevFrontend OK — pont inter-agent fonctionnel", (2) le résultat de 144 ÷ 12, et (3) l'heure courante. Aucune autre action requise.
+- **Prompt:** Test de conversation inter-agent. Calcule 123 × 4 et réponds-moi simplement avec le résultat via idea_reply.
+- **Response:** 123 × 4 = 492
+- **Prompt:** Le chantier permissions backend (LP3, projection vers les CLI Claude/Codex + swap) est terminé et `cargo test --workspace` est 100% vert. Mais `npx vitest run` côté frontend a 4 échecs, signalés comme pré-existants liés au chantier UI permissions en cours (gateway permissions ajoutée, PermissionsPanel monté dans ProjectsView). Diagnostique-les et corrige-les pour remettre le frontend au vert. Lance d'abord : `cd frontend && npx vitest run` pour voir l'état réel. Les 4 échecs rapportés : 1. `mock.test.ts > exposes all thirteen gateways` — le mock expose désormais une gateway de plus (permissions ⇒ 14). Mets à jour le test ET vérifie que le mock (`frontend/src/adapters/mock/index.ts`) expose bien une gateway permissions cohérente avec le port réel (`TauriPermissionGateway`). Le titre du test (« thirteen ») et le compte attendu doivent refléter le vrai nombre de gateways. 2. `LayoutGrid.chat.test.tsx` (2 échecs) — routage cellule terminal/chat. 3. `agentAlreadyRunning.test.tsx` (1 échec) — notice R0d. POUR CHAQUE échec : déterminer si c'est (a) un test à mettre à jour parce que le comportement/contrat a légitimement changé avec le feature permissions, ou (b) une vraie régression du code à corriger. Explique ton verdict pour chacun. Ne « fais pas passer » un test en masquant un vrai bug — si 2 et 3 ne sont pas liés aux permissions et révèlent une régression réelle, dis-le clairement plutôt que de les bricoler. Vérifie aussi qu'il n'y a pas d'incohérence entre le port permissions (`frontend/src/ports/index.ts`), l'adapter Tauri (`frontend/src/adapters/permission.ts`), le mock, et les types domaine (`frontend/src/domain/index.ts`) — les 4 doivent être alignés. Quand c'est fini, réponds via idea_reply : verdict par échec (test à jour vs régression corrigée), ce que tu as changé, et la SORTIE RÉELLE de `npx vitest run` (doit être 100% vert). Si un échec est une vraie régression hors de ton périmètre permissions, signale-le précisément.
+- **Prompt:** [Test de communication inter-agent] Ping. Réponds simplement via idea_reply avec « pong DevFrontend OK » pour confirmer que le canal fonctionne.
+- **Response:** pong DevFrontend OK
+- **Prompt:** Tâche : nettoyage/correction de bugs d'affichage UI (frontend React/TS). Project root : /home/anthony/Documents/Projects/IdeA. Aucune nouvelle feature, uniquement du fix CSS/layout. Voici 3 problèmes constatés visuellement (captures non transmissibles, je les décris) : PROBLÈME 1 — Barre de navigation horizontale (top bar listant : Projects, Context, Agents, Templates, Skills, Permissions, …). - Cette barre n'est PAS scrollable et n'est PAS correctement mise à l'échelle. Quand il y a trop d'entrées, les derniers items débordent et sont coupés (on voit « Skills » puis « P… » tronqué, « Permissions » coupé). - Attendu : la barre doit gérer le débordement proprement — soit scroll horizontal (overflow-x:auto avec masquage de scrollbar propre), soit wrap/scale correct. Les entrées ne doivent jamais être croppées. Vérifier flex-shrink/min-width des items. PROBLÈME 2 — Panneau « Agents » (liste des agents : Main, Architect, DevBackend, DevFrontend, QA, TestConversation, …). - Les items de la liste s'overlappent (chevauchement vertical) et sont croppés. Le nom de l'agent, le profil (« Claude Code »), l'id de run (longue chaîne en bleu qui wrap mal sur plusieurs lignes), la dropdown de profil et les boutons Stop/Delete/Launch se chevauchent et débordent du panneau. - Attendu : chaque carte d'agent doit avoir une hauteur qui s'adapte à son contenu (pas de height fixe qui cause l'overlap), les éléments alignés proprement, l'id long tronqué avec ellipsis ou wrap contrôlé, et la dropdown + boutons ne doivent pas déborder/chevaucher le texte voisin. Vérifier les position absolute éventuels et les gaps flex/grid. PROBLÈME 3 — Formulaire de création d'agent (champs : Name, Template, Profile, bouton Create). - Les champs du formulaire s'overlappent les uns sur les autres (Name / Template / Profile trop serrés/superposés). - BUG fonctionnel : quand on sélectionne une valeur dans les dropdowns (Template / Profile), la sélection NE s'affiche PAS dans le champ de la droplist (le label sélectionné ne se reflète pas visuellement). À investiguer : binding value/onChange du composant select, ou affichage du label sélectionné si c'est un dropdown custom. - Attendu : formulaire avec espacement correct (pas de chevauchement), et les dropdowns affichent bien la valeur choisie. Merci de : 1. Localiser les composants concernés (top nav bar, panneau Agents, formulaire création d'agent). 2. Corriger le CSS/layout et le bug de binding des dropdowns. 3. Lancer un build frontend pour t'assurer que ça compile (npm run build ou équivalent), sans casser le reste. 4. Me renvoyer via idea_reply la liste des fichiers modifiés + un résumé des corrections, pour que je puisse enchaîner sur le rebuild de l'AppImage.
+- **Response:** Bugs d'affichage corrigés. Build vert (`npm run build` = tsc --noEmit + vite build OK) et tests verts (`vitest run` agents + projects : 47/47 passent). ## Fichiers modifiés (2) - `frontend/src/features/projects/ProjectsView.tsx` — la « top bar » - `frontend/src/features/agents/AgentsPanel.tsx` — panneau Agents + formulaire de création ## Diagnostic La « top bar » décrite n'est pas une nav OS mais le **strip de tabs du sidebar** (`SIDEBAR_TABS` : Projects, Context, Agents, Templates, Skills, Perms, Memory, Git) dans `ProjectsView.tsx`. Cause racine commune aux 3 problèmes : **largeur trop contrainte** dans le sidebar de 320px (`w-80`). ## Corrections **PROBLÈME 1 — barre de tabs croppée** - Avant : 8 boutons en `flex-1` sans gestion de débordement → les derniers labels coupés. - Après : les tabs sont dans un conteneur `overflow-x-auto` **scrollable horizontalement**, chaque tab passe en `shrink-0 whitespace-nowrap` (plus jamais croppé). Scrollbar masquée proprement (`[scrollbar-width:none]` + `[&::-webkit-scrollbar]:hidden`). Le bouton « collapse » («) reste épinglé à droite, hors zone de scroll. **PROBLÈME 2 — cartes d'agents qui se chevauchent** - Avant : `<li>` en `flex items-center justify-between` → le bloc nom/profil et la colonne de contrôles (dropdown profil + Sync/Stop/Launch/Delete, en `shrink-0`) se disputaient la largeur ; l'id de run long (`running in IdeA · <id>`) wrappait et débordait. - Après : carte en **`flex-col`** — bloc nom/profil/statut en haut, rangée de contrôles en dessous (`flex-wrap`, plus de `shrink-0` qui écrasait le texte). Hauteur adaptative au contenu (plus de chevauchement). L'id long est désormais **tronqué avec ellipsis** (`block w-full min-w-0 truncate`). **PROBLÈME 3 — formulaire de création (champs serrés + dropdowns « vides »)** - Avant : form en `flex flex-wrap items-end` avec 3 champs `min-w-0 flex-1` → selects écrasés à ~90px ; le texte sélectionné (« Claude Code ») était **clippé derrière la flèche native** du select, d'où l'impression que la sélection ne s'affichait pas. - Après : form en **`flex-col gap-3`**, chaque champ en pleine largeur. Le binding des `<select>` était déjà correct (`value`/`onChange` contrôlés, natifs) — c'était bien un problème de largeur, pas de binding. En pleine largeur la valeur choisie s'affiche normalement. Bouton Create passé en `self-end`. Aucune nouvelle dépendance, aucun changement de logique métier ni de contrat IPC/gateway. Les tests s'appuient sur les `aria-label` (inchangés), d'où les 47/47 verts. Tu peux enchaîner sur le rebuild de l'AppImage (rappel mémoire : c'est l'AppImage qui tourne qu'il faut reconstruire, pas seulement les sources).
+- **Prompt:** Tâche LS7-front (React/TS) — UI de gestion des limites de session des agents (ARCHITECTURE §21). On est sur la branche `feature/agent-session-limits`. Le backend est terminé et vert (commit 9df5923) : il émet déjà 5 DOMAIN_EVENT vers le front et expose une commande Tauri `cancel_resume(agentId) -> bool`. CONTRAT WIRE (DTO sérialisés camelCase, source = crates/app-tauri/src/events.rs) : - `agentRateLimited` { agentId: string, resetsAt?: number /* epoch-ms, absent si inconnu */ } - `agentResumeScheduled` { agentId: string, fireAt: number /* epoch-ms, échéance du réveil */ } ⚠️ champ wire = `fireAtMs` → vérifie le nom exact sérialisé (camelCase de `fire_at_ms` = `fireAtMs`) ; idem `resetsAtMs` pour les autres. Aligne-toi sur le JSON réel. - `agentResumeCancelled` { agentId: string } - `agentResumed` { agentId: string } - `agentRateLimitSuspected` { agentId: string, resetsAt?: number } (Vérifie les noms de champs exacts dans events.rs : `resets_at_ms`→`resetsAtMs`, `fire_at_ms`→`fireAtMs`. Ne devine pas, lis le fichier.) À FAIRE : 1) Ajouter les 5 variantes au union `DomainEvent` de `src/domain/index.ts` (mêmes noms `type` que le wire), avec les champs exacts. 2) Exposer la commande `cancel_resume` dans le port gateway approprié (cf. `src/ports/index.ts`) + son implémentation dans l'adapter système (`src/adapters/system.ts`) ET le mock (`src/adapters/mock/index.ts`). RÈGLE ARCHI STRICTE : les composants ne touchent JAMAIS `invoke()` ni `@tauri-apps/api` — tout passe par les gateways/ports (hexagonal §1.3). Suis le patron d'une commande existante (ex. `interruptAgent` si elle existe, sinon une autre commande agent). 3) Tracker l'état limite par agent dans `useAgents` (view-model hook). Inspire-toi du patron existant `delegationSourceByRequester` qui se peuple depuis les events. État par agent : { limitedUntil?: number, resumeFireAt?: number, suspected?: bool }. Mises à jour : - `agentRateLimited` → limité (badge « limité jusqu'à HH:MM » si resetsAt connu, sinon « limité »). - `agentResumeScheduled` → arme le compte à rebours jusqu'à fireAt + bouton « Annuler la reprise ». - `agentResumeCancelled` → retire le compte à rebours (reste limité, sans reprise auto). - `agentResumed` → efface tout l'état limite de l'agent. - `agentRateLimitSuspected` → filet humain : signaler que la limite est détectée sans heure fiable et demander à l'utilisateur (au minimum un état/affichage « heure inconnue » ; le formulaire de saisie d'heure peut être un placeholder documenté si le backend n'a pas encore de commande pour l'enregistrer — dans ce cas, expose juste l'état et un TODO clair, NE fabrique pas de commande inexistante). 4) UI : badge limite + compte à rebours + bouton « Annuler la reprise » (appelle `cancel_resume` via le gateway) dans la vue agents/terminal cohérente avec le style existant. Composant testable (gateways mockés). NE PAS committer toi-même (l'agent Git tranche les commits). NE PAS toucher au backend Rust. Reste cohérent avec le style TS/React existant. Quand c'est implémenté, QA écrira/exécutera les tests — donc structure pour la testabilité (logique d'état dans le hook, pas dans le JSX). Rends-moi via idea_reply : la liste des fichiers modifiés/créés, les noms de champs wire exacts que tu as constatés dans events.rs, et tout point de friction (notamment sur le filet humain niveau 3 si aucune commande backend n'existe pour enregistrer l'heure saisie).
+- **Response:** LS7-front terminé. Typecheck `tsc --noEmit` propre + 39 tests agents existants verts (aucune régression). Non commité (Git tranche). ## Noms de champs wire constatés (lus dans crates/app-tauri/src/events.rs, `DomainEventDto`, serde camelCase + skip_serializing_if sur les Option) - `agentRateLimited` → { `agentId`: string, `resetsAtMs`?: number /* absent si null */ } - `agentResumeScheduled` → { `agentId`: string, `fireAtMs`: number /* toujours présent */ } - `agentResumeCancelled` → { `agentId`: string } - `agentResumed` → { `agentId`: string } - `agentRateLimitSuspected` → { `agentId`: string, `resetsAtMs`?: number /* absent si null */ } ⚠️ Confirmé : ce sont bien `resetsAtMs` / `fireAtMs` (suffixe `Ms`), PAS `resetsAt`/`fireAt` comme l'énoncé du ticket le suggérait. Je me suis aligné sur le JSON réel. Vérifié aussi par le test backend `rate_limited_relays_to_dto_and_wire` qui asserte `json["resetsAtMs"]`. Commande Tauri `cancel_resume` (commands.rs:1381) : signature `cancel_resume(agent_id: String) -> Result<bool, _>` — argument **nu** `agentId` (PAS d'enveloppe `{ request }` contrairement à interrupt_agent/delegation_delivered). Adapter aligné en conséquence. Renvoie `true` ssi une reprise était armée et a été désarmée. ## Fichiers modifiés 1. `frontend/src/domain/index.ts` — 5 variantes ajoutées au union `DomainEvent` (mêmes `type` que le wire, champs exacts `resetsAtMs?`/`fireAtMs`). 2. `frontend/src/ports/index.ts` — `cancelResume(agentId: string): Promise<boolean>` ajouté à `InputGateway` (port choisi : c'est le gateway des contrôles agent hors-bande, cohérent avec `interrupt`). 3. `frontend/src/adapters/input.ts` — `TauriInputGateway.cancelResume` → `invoke("cancel_resume", { agentId })` (arg nu, typé `<boolean>`). 4. `frontend/src/adapters/mock/index.ts` — `MockInputGateway.cancelResume` : enregistre dans `cancelledResumes: string[]`, renvoie `cancelResumeResult` (défaut `true`, flippable par les tests). 5. `frontend/src/features/agents/useAgents.ts` — état `limitByAgent: Record<string, AgentLimitState>` (interface exportée `{ limitedUntil?, resumeFireAt?, suspected? }`), peuplé depuis les 5 events dans l'abonnement `onDomainEvent` existant (même patron que `delegationSourceByRequester`) : - `agentRateLimited` → `{ limitedUntil: resetsAtMs, suspected: false }` (conserve un `resumeFireAt` éventuel). - `agentResumeScheduled` → arme `resumeFireAt = fireAtMs`. - `agentResumeCancelled` → retire `resumeFireAt`, reste limité. - `agentResumed` → supprime l'entrée (efface tout). - `agentRateLimitSuspected` → `{ limitedUntil: resetsAtMs, suspected: true }`. - Action `cancelResume(agentId)` exposée : retrait optimiste du compte à rebours + appel `input.cancelResume`, renvoie le verdict backend. ## Fichier créé 6. `frontend/src/features/agents/AgentLimitBadge.tsx` — composant présentational + 2 helpers purs exportés (`formatResetTime(epochMs)` → `HH:MM`, `formatCountdown(remainingMs)` → `Xm Ys`/`Ys`, clampé à 0). Badge « limité jusqu'à HH:MM » / « limité », compte à rebours vivant (clock locale 1 s armée seulement si `resumeFireAt`), bouton « Annuler la reprise ». Câblé dans `AgentsPanel.tsx` (import + rendu conditionnel sous chaque ligne d'agent quand `vm.limitByAgent[a.id]` existe). ## Point de friction — filet humain niveau 3 (§21.1) Conformément à la consigne, je n'ai **fabriqué aucune commande inexistante**. Le seul point d'entrée backend disponible est `cancel_resume` ; **il n'existe pas de commande pour enregistrer une heure de reprise saisie par l'utilisateur**. Donc pour `agentRateLimitSuspected` sans `resetsAtMs`, le badge affiche l'état « limité · heure inconnue — reprise à préciser » (état + `role="note"`), sans formulaire de saisie. Un `TODO(LS-front)` documenté est posé dans `AgentLimitBadge.tsx` : câbler un formulaire d'heure dès que le backend exposera une commande pour persister l'instant choisi. Si tu veux ce filet pleinement fonctionnel, il faut une tâche backend (ex. `set_resume_at(agentId, epochMs)`) à cadrer avec Architect/DevBackend — je m'y connecterai côté front. Prêt pour QA (logique d'état dans le hook + helpers purs isolés du JSX, mocks en place avec `cancelledResumes`/`cancelResumeResult`).
+- **Prompt:** Deux livrables distincts sur `feature/agent-session-limits` (Git en fera 2 commits séparés — ne commit pas toi-même). ═══ LIVRABLE 1 — LS8-front : formulaire de saisie d'heure (filet humain niveau 3) ═══ Le backend expose maintenant une commande Tauri `set_resume_at(agentId: string, resetsAtMs: number) -> void` (argument nu `{ agentId, resetsAtMs }`, comme `cancel_resume`). Elle arme la MÊME reprise annulable que l'auto et réémet `agentResumeScheduled` — donc une fois appelée, ton badge bascule TOUT SEUL de « heure inconnue » vers l'état nominal « limité jusqu'à HH:MM » + compte à rebours + bouton Annuler (déjà câblés en LS7). Aucun nouvel événement à consommer. À FAIRE : 1. Port : ajoute `setResumeAt(agentId: string, resetsAtMs: number): Promise<void>` à `InputGateway` (`src/ports/index.ts`), à côté de `cancelResume`. 2. Adapter Tauri (`src/adapters/input.ts`) : `setResumeAt` → `invoke("set_resume_at", { agentId, resetsAtMs })`. 3. Mock (`src/adapters/mock/index.ts`) : `MockInputGateway.setResumeAt` enregistre dans un tableau (ex. `resumeArmings: { agentId, resetsAtMs }[]`) pour les tests ; suis le patron de `cancelledResumes`. 4. Hook `useAgents` : expose une action `setResumeAt(agentId, resetsAtMs)` qui délègue au port (pas de mutation optimiste nécessaire — l'event `agentResumeScheduled` rebasculera l'état). 5. UI `AgentLimitBadge.tsx` : sur l'état SUSPECTED SANS heure (`suspected === true` && pas de `limitedUntil`/`resumeFireAt`), remplace le TODO/placeholder par un petit formulaire : un input heure (type `time` ou `datetime-local`) + bouton « Programmer la reprise ». À la soumission : convertir la saisie en epoch-ms (si input `time` seul = aujourd'hui à HH:MM ; si déjà passé dans la journée, le backend clampe à maintenant ⇒ reprise immédiate, donc pas besoin de validation stricte côté front, mais documente le comportement). Appeler l'action `setResumeAt(agentId, epochMs)`. Garde un helper pur exporté pour la conversion (ex. `timeInputToEpochMs(value, now)`) pour la testabilité. Style cohérent avec le reste du badge ; désactive pendant `busy`. 6. Retire le `TODO(LS-front)` posé en LS7 (le filet est maintenant complet). ═══ LIVRABLE 2 — fix test préexistant (hygiène, commit séparé) ═══ `src/adapters/mock/mock.test.ts:16` asserte « thirteen gateways » mais il y en a 14 (la gateway `permission` existe déjà dans HEAD). Mets le compteur à jour (14, et le libellé texte si présent) pour que `npx vitest run src/adapters/mock/` repasse vert. NE change RIEN d'autre dans ce fichier ; vérifie juste que le compte réel est bien 14 avant de figer le nombre. Lance `npx vitest run src/features/agents/ src/adapters/mock/` + `tsc --noEmit` et RENDS-MOI via idea_reply : fichiers modifiés/créés par livrable, le helper de conversion exact, le résultat des deux commandes (typecheck + tests), et le nombre réel de gateways constaté. Structure pour testabilité (logique dans le hook + helpers purs). NE COMMIT PAS — Git tranche, en 2 commits séparés (LS8-front / fix-test).
+- **Response:** Les deux livrables sont prêts. NON commité (Git tranche, 2 commits séparés). ## Résultats des commandes - `npx tsc --noEmit` : **propre** (0 erreur). - `npx vitest run src/features/agents/ src/adapters/mock/` : **109 tests / 8 fichiers, tous verts**. ## Nombre réel de gateways constaté : **14** Le `Gateways` (ports/index.ts) en a 14 ; l'array du test en listait 13 — il manquait `permission` (présente dans HEAD). Compteur + libellé + array corrigés. ## Helper de conversion exact (pur, exporté, testé) ```ts // AgentLimitBadge.tsx export function timeInputToEpochMs(value: string, now: number): number | null { const match = /^(\d{1,2}):(\d{2})$/.exec(value.trim()); if (!match) return null; const hours = Number(match[1]); const minutes = Number(match[2]); if (hours > 23 || minutes > 59) return null; const d = new Date(now); d.setHours(hours, minutes, 0, 0); return d.getTime(); } ``` Comportement documenté : input `time` seul ⇒ aujourd'hui à HH:MM (même jour calendaire que `now`). Une heure déjà passée renvoie un instant < now **sans validation stricte** — le backend clampe à maintenant ⇒ reprise immédiate (commenté dans le code et couvert par un test). Empty/malformé/`25:00`/`12:60` ⇒ `null` (saisie incomplète ignorée). ═══ LIVRABLE 1 — LS8-front (commit « LS8-front ») ═══ Fichiers modifiés : 1. `frontend/src/ports/index.ts` — `setResumeAt(agentId, resetsAtMs): Promise<void>` ajouté à `InputGateway`, à côté de `cancelResume`. 2. `frontend/src/adapters/input.ts` — `setResumeAt` → `invoke("set_resume_at", { agentId, resetsAtMs })` (args nus, comme cancel_resume). 3. `frontend/src/adapters/mock/index.ts` — `MockInputGateway.setResumeAt` enregistre dans `resumeArmings: { agentId, resetsAtMs }[]` (patron `cancelledResumes`). 4. `frontend/src/features/agents/useAgents.ts` — action `setResumeAt(agentId, resetsAtMs)` exposée, délègue au port, **aucune mutation optimiste** (l'event `agentResumeScheduled` rebascule l'état via l'abonnement existant). 5. `frontend/src/features/agents/AgentLimitBadge.tsx` — état SUSPECTED sans heure (`suspected===true && !limitedUntil && !resumeFireAt`) : le placeholder/TODO LS7 est remplacé par un **formulaire** (input `type="time"` aria-label `resume time` + bouton `Programmer la reprise` aria-label `schedule resume`, désactivés pendant `busy`/saisie vide). Soumission → `timeInputToEpochMs` → `onSetResumeAt(epochMs)`. Une fois armé, le badge bascule **tout seul** vers « limité jusqu'à HH:MM » + compte à rebours + Annuler (chaîne LS7 inchangée). TODO(LS-front) **retiré**. 6. `frontend/src/features/agents/AgentsPanel.tsx` — passe `onSetResumeAt={(ms) => void vm.setResumeAt(a.id, ms)}` au badge. 7. `frontend/src/features/agents/AgentLimitBadge.test.tsx` — **test QA préexistant (LS7) mis à jour au nouveau contrat** (prop requise `onSetResumeAt`, le cas « suspected sans heure » teste maintenant le formulaire au lieu de l'ancien texte placeholder) + ajout couverture LS8 : `timeInputToEpochMs` (jour calendaire, instant passé, null malformé), soumission du formulaire ⇒ `onSetResumeAt` appelé avec l'epoch-ms attendu, bouton désactivé si vide. *(Sans cette MAJ le typecheck cassait — la prop est devenue obligatoire et le rendu du cas suspected a changé. Aucune logique de prod altérée, seulement l'alignement du test.)* ═══ LIVRABLE 2 — fix test (commit « fix-test » séparé) ═══ Fichier modifié : - `frontend/src/adapters/mock/mock.test.ts` — « thirteen » → « fourteen », `"permission"` inséré dans l'array attendu (ordre alphabétique). **Rien d'autre touché** dans ce fichier. ## Point de friction / note Petit ajustement non listé mais nécessaire : le `<form>` portait initialement le même `aria-label="schedule resume"` que son bouton submit, ce qui faisait matcher 2 éléments avec `getByLabelText`. J'ai renommé le label du form en `"resume time form"` (le bouton garde `schedule resume`). Aucune incidence fonctionnelle. Le filet humain niveau 3 est désormais **complet** : détection → formulaire de saisie → arme la reprise annulable via `set_resume_at` → bascule auto vers l'état nominal. Prêt pour QA (logique d'état dans le hook, helpers purs isolés, mocks instrumentés `resumeArmings`/`cancelledResumes`).

.ideai/conversations/09b15ec3-ce2f-0af2-2903-ef699df9de41/log.jsonl

@@ -0,0 +1,12 @@
+{"id":"f473c5bc-e6b6-4efd-927d-452cb587fac2","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781517530284,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"[Ping inter-agent depuis Main] Test du pont MCP inter-agents. Si tu reçois ce message, réponds via idea_reply avec : (1) \"DevFrontend OK — pont inter-agent fonctionnel\", (2) le résultat de 144 ÷ 12, et (3) l'heure courante. Aucune autre action requise."}
+{"id":"63f0981d-a083-4b21-97fb-e5d681b99468","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781522526877,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Test de conversation inter-agent. Calcule 123 × 4 et réponds-moi simplement avec le résultat via idea_reply."}
+{"id":"223e1427-7aad-4de2-ab3a-ac08f90e1256","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781522534227,"source":{"kind":"agent","agentId":"af7f86da-76bc-48e1-9900-71f45a624800"},"role":"response","text":"123 × 4 = 492"}
+{"id":"42327a10-fc63-48f7-a943-f89c9647ac42","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781526082185,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Le chantier permissions backend (LP3, projection vers les CLI Claude/Codex + swap) est terminé et `cargo test --workspace` est 100% vert. Mais `npx vitest run` côté frontend a 4 échecs, signalés comme pré-existants liés au chantier UI permissions en cours (gateway permissions ajoutée, PermissionsPanel monté dans ProjectsView). Diagnostique-les et corrige-les pour remettre le frontend au vert.\n\nLance d'abord : `cd frontend && npx vitest run` pour voir l'état réel.\n\nLes 4 échecs rapportés :\n1. `mock.test.ts > exposes all thirteen gateways` — le mock expose désormais une gateway de plus (permissions ⇒ 14). Mets à jour le test ET vérifie que le mock (`frontend/src/adapters/mock/index.ts`) expose bien une gateway permissions cohérente avec le port réel (`TauriPermissionGateway`). Le titre du test (« thirteen ») et le compte attendu doivent refléter le vrai nombre de gateways.\n2. `LayoutGrid.chat.test.tsx` (2 échecs) — routage cellule terminal/chat.\n3. `agentAlreadyRunning.test.tsx` (1 échec) — notice R0d.\n\nPOUR CHAQUE échec : déterminer si c'est (a) un test à mettre à jour parce que le comportement/contrat a légitimement changé avec le feature permissions, ou (b) une vraie régression du code à corriger. Explique ton verdict pour chacun. Ne « fais pas passer » un test en masquant un vrai bug — si 2 et 3 ne sont pas liés aux permissions et révèlent une régression réelle, dis-le clairement plutôt que de les bricoler.\n\nVérifie aussi qu'il n'y a pas d'incohérence entre le port permissions (`frontend/src/ports/index.ts`), l'adapter Tauri (`frontend/src/adapters/permission.ts`), le mock, et les types domaine (`frontend/src/domain/index.ts`) — les 4 doivent être alignés.\n\nQuand c'est fini, réponds via idea_reply : verdict par échec (test à jour vs régression corrigée), ce que tu as changé, et la SORTIE RÉELLE de `npx vitest run` (doit être 100% vert). Si un échec est une vraie régression hors de ton périmètre permissions, signale-le précisément."}
+{"id":"2a7f8f6d-3163-496a-a5b8-764a4229a40f","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781544382139,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"[Test de communication inter-agent] Ping. Réponds simplement via idea_reply avec « pong DevFrontend OK » pour confirmer que le canal fonctionne."}
+{"id":"6a286e41-aa26-4bcb-8530-282bd09dde95","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781544388479,"source":{"kind":"agent","agentId":"af7f86da-76bc-48e1-9900-71f45a624800"},"role":"response","text":"pong DevFrontend OK"}
+{"id":"808e5ed2-57d7-4839-906e-bd66886852b7","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781593284048,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Tâche : nettoyage/correction de bugs d'affichage UI (frontend React/TS). Project root : /home/anthony/Documents/Projects/IdeA. Aucune nouvelle feature, uniquement du fix CSS/layout. Voici 3 problèmes constatés visuellement (captures non transmissibles, je les décris) :\n\nPROBLÈME 1 — Barre de navigation horizontale (top bar listant : Projects, Context, Agents, Templates, Skills, Permissions, …).\n- Cette barre n'est PAS scrollable et n'est PAS correctement mise à l'échelle. Quand il y a trop d'entrées, les derniers items débordent et sont coupés (on voit « Skills » puis « P… » tronqué, « Permissions » coupé).\n- Attendu : la barre doit gérer le débordement proprement — soit scroll horizontal (overflow-x:auto avec masquage de scrollbar propre), soit wrap/scale correct. Les entrées ne doivent jamais être croppées. Vérifier flex-shrink/min-width des items.\n\nPROBLÈME 2 — Panneau « Agents » (liste des agents : Main, Architect, DevBackend, DevFrontend, QA, TestConversation, …).\n- Les items de la liste s'overlappent (chevauchement vertical) et sont croppés. Le nom de l'agent, le profil (« Claude Code »), l'id de run (longue chaîne en bleu qui wrap mal sur plusieurs lignes), la dropdown de profil et les boutons Stop/Delete/Launch se chevauchent et débordent du panneau.\n- Attendu : chaque carte d'agent doit avoir une hauteur qui s'adapte à son contenu (pas de height fixe qui cause l'overlap), les éléments alignés proprement, l'id long tronqué avec ellipsis ou wrap contrôlé, et la dropdown + boutons ne doivent pas déborder/chevaucher le texte voisin. Vérifier les position absolute éventuels et les gaps flex/grid.\n\nPROBLÈME 3 — Formulaire de création d'agent (champs : Name, Template, Profile, bouton Create).\n- Les champs du formulaire s'overlappent les uns sur les autres (Name / Template / Profile trop serrés/superposés).\n- BUG fonctionnel : quand on sélectionne une valeur dans les dropdowns (Template / Profile), la sélection NE s'affiche PAS dans le champ de la droplist (le label sélectionné ne se reflète pas visuellement). À investiguer : binding value/onChange du composant select, ou affichage du label sélectionné si c'est un dropdown custom.\n- Attendu : formulaire avec espacement correct (pas de chevauchement), et les dropdowns affichent bien la valeur choisie.\n\nMerci de :\n1. Localiser les composants concernés (top nav bar, panneau Agents, formulaire création d'agent).\n2. Corriger le CSS/layout et le bug de binding des dropdowns.\n3. Lancer un build frontend pour t'assurer que ça compile (npm run build ou équivalent), sans casser le reste.\n4. Me renvoyer via idea_reply la liste des fichiers modifiés + un résumé des corrections, pour que je puisse enchaîner sur le rebuild de l'AppImage."}
+{"id":"a6169530-fc73-4057-91c6-900da4a611fb","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781593486944,"source":{"kind":"agent","agentId":"af7f86da-76bc-48e1-9900-71f45a624800"},"role":"response","text":"Bugs d'affichage corrigés. Build vert (`npm run build` = tsc --noEmit + vite build OK) et tests verts (`vitest run` agents + projects : 47/47 passent).\n\n## Fichiers modifiés (2)\n- `frontend/src/features/projects/ProjectsView.tsx` — la « top bar »\n- `frontend/src/features/agents/AgentsPanel.tsx` — panneau Agents + formulaire de création\n\n## Diagnostic\nLa « top bar » décrite n'est pas une nav OS mais le **strip de tabs du sidebar** (`SIDEBAR_TABS` : Projects, Context, Agents, Templates, Skills, Perms, Memory, Git) dans `ProjectsView.tsx`. Cause racine commune aux 3 problèmes : **largeur trop contrainte** dans le sidebar de 320px (`w-80`).\n\n## Corrections\n\n**PROBLÈME 1 — barre de tabs croppée**\n- Avant : 8 boutons en `flex-1` sans gestion de débordement → les derniers labels coupés.\n- Après : les tabs sont dans un conteneur `overflow-x-auto` **scrollable horizontalement**, chaque tab passe en `shrink-0 whitespace-nowrap` (plus jamais croppé). Scrollbar masquée proprement (`[scrollbar-width:none]` + `[&::-webkit-scrollbar]:hidden`). Le bouton « collapse » («) reste épinglé à droite, hors zone de scroll.\n\n**PROBLÈME 2 — cartes d'agents qui se chevauchent**\n- Avant : `<li>` en `flex items-center justify-between` → le bloc nom/profil et la colonne de contrôles (dropdown profil + Sync/Stop/Launch/Delete, en `shrink-0`) se disputaient la largeur ; l'id de run long (`running in IdeA · <id>`) wrappait et débordait.\n- Après : carte en **`flex-col`** — bloc nom/profil/statut en haut, rangée de contrôles en dessous (`flex-wrap`, plus de `shrink-0` qui écrasait le texte). Hauteur adaptative au contenu (plus de chevauchement). L'id long est désormais **tronqué avec ellipsis** (`block w-full min-w-0 truncate`).\n\n**PROBLÈME 3 — formulaire de création (champs serrés + dropdowns « vides »)**\n- Avant : form en `flex flex-wrap items-end` avec 3 champs `min-w-0 flex-1` → selects écrasés à ~90px ; le texte sélectionné (« Claude Code ») était **clippé derrière la flèche native** du select, d'où l'impression que la sélection ne s'affichait pas.\n- Après : form en **`flex-col gap-3`**, chaque champ en pleine largeur. Le binding des `<select>` était déjà correct (`value`/`onChange` contrôlés, natifs) — c'était bien un problème de largeur, pas de binding. En pleine largeur la valeur choisie s'affiche normalement. Bouton Create passé en `self-end`.\n\nAucune nouvelle dépendance, aucun changement de logique métier ni de contrat IPC/gateway. Les tests s'appuient sur les `aria-label` (inchangés), d'où les 47/47 verts.\n\nTu peux enchaîner sur le rebuild de l'AppImage (rappel mémoire : c'est l'AppImage qui tourne qu'il faut reconstruire, pas seulement les sources)."}
+{"id":"9b53cc9b-ffed-42c9-9961-fefb5aca677e","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781675890156,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Tâche LS7-front (React/TS) — UI de gestion des limites de session des agents (ARCHITECTURE §21). On est sur la branche `feature/agent-session-limits`. Le backend est terminé et vert (commit 9df5923) : il émet déjà 5 DOMAIN_EVENT vers le front et expose une commande Tauri `cancel_resume(agentId) -> bool`.\n\nCONTRAT WIRE (DTO sérialisés camelCase, source = crates/app-tauri/src/events.rs) :\n- `agentRateLimited` { agentId: string, resetsAt?: number /* epoch-ms, absent si inconnu */ }\n- `agentResumeScheduled` { agentId: string, fireAt: number /* epoch-ms, échéance du réveil */ }  ⚠️ champ wire = `fireAtMs` → vérifie le nom exact sérialisé (camelCase de `fire_at_ms` = `fireAtMs`) ; idem `resetsAtMs` pour les autres. Aligne-toi sur le JSON réel.\n- `agentResumeCancelled` { agentId: string }\n- `agentResumed` { agentId: string }\n- `agentRateLimitSuspected` { agentId: string, resetsAt?: number }\n(Vérifie les noms de champs exacts dans events.rs : `resets_at_ms`→`resetsAtMs`, `fire_at_ms`→`fireAtMs`. Ne devine pas, lis le fichier.)\n\nÀ FAIRE :\n1) Ajouter les 5 variantes au union `DomainEvent` de `src/domain/index.ts` (mêmes noms `type` que le wire), avec les champs exacts.\n2) Exposer la commande `cancel_resume` dans le port gateway approprié (cf. `src/ports/index.ts`) + son implémentation dans l'adapter système (`src/adapters/system.ts`) ET le mock (`src/adapters/mock/index.ts`). RÈGLE ARCHI STRICTE : les composants ne touchent JAMAIS `invoke()` ni `@tauri-apps/api` — tout passe par les gateways/ports (hexagonal §1.3). Suis le patron d'une commande existante (ex. `interruptAgent` si elle existe, sinon une autre commande agent).\n3) Tracker l'état limite par agent dans `useAgents` (view-model hook). Inspire-toi du patron existant `delegationSourceByRequester` qui se peuple depuis les events. État par agent : { limitedUntil?: number, resumeFireAt?: number, suspected?: bool }. Mises à jour :\n   - `agentRateLimited` → limité (badge « limité jusqu'à HH:MM » si resetsAt connu, sinon « limité »).\n   - `agentResumeScheduled` → arme le compte à rebours jusqu'à fireAt + bouton « Annuler la reprise ».\n   - `agentResumeCancelled` → retire le compte à rebours (reste limité, sans reprise auto).\n   - `agentResumed` → efface tout l'état limite de l'agent.\n   - `agentRateLimitSuspected` → filet humain : signaler que la limite est détectée sans heure fiable et demander à l'utilisateur (au minimum un état/affichage « heure inconnue » ; le formulaire de saisie d'heure peut être un placeholder documenté si le backend n'a pas encore de commande pour l'enregistrer — dans ce cas, expose juste l'état et un TODO clair, NE fabrique pas de commande inexistante).\n4) UI : badge limite + compte à rebours + bouton « Annuler la reprise » (appelle `cancel_resume` via le gateway) dans la vue agents/terminal cohérente avec le style existant. Composant testable (gateways mockés).\n\nNE PAS committer toi-même (l'agent Git tranche les commits). NE PAS toucher au backend Rust. Reste cohérent avec le style TS/React existant. Quand c'est implémenté, QA écrira/exécutera les tests — donc structure pour la testabilité (logique d'état dans le hook, pas dans le JSX).\n\nRends-moi via idea_reply : la liste des fichiers modifiés/créés, les noms de champs wire exacts que tu as constatés dans events.rs, et tout point de friction (notamment sur le filet humain niveau 3 si aucune commande backend n'existe pour enregistrer l'heure saisie)."}
+{"id":"a37b2aac-87f7-476d-8606-7250d15dd852","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781676130924,"source":{"kind":"agent","agentId":"af7f86da-76bc-48e1-9900-71f45a624800"},"role":"response","text":"LS7-front terminé. Typecheck `tsc --noEmit` propre + 39 tests agents existants verts (aucune régression). Non commité (Git tranche).\n\n## Noms de champs wire constatés (lus dans crates/app-tauri/src/events.rs, `DomainEventDto`, serde camelCase + skip_serializing_if sur les Option)\n- `agentRateLimited` → { `agentId`: string, `resetsAtMs`?: number /* absent si null */ }\n- `agentResumeScheduled` → { `agentId`: string, `fireAtMs`: number /* toujours présent */ }\n- `agentResumeCancelled` → { `agentId`: string }\n- `agentResumed` → { `agentId`: string }\n- `agentRateLimitSuspected` → { `agentId`: string, `resetsAtMs`?: number /* absent si null */ }\n\n⚠️ Confirmé : ce sont bien `resetsAtMs` / `fireAtMs` (suffixe `Ms`), PAS `resetsAt`/`fireAt` comme l'énoncé du ticket le suggérait. Je me suis aligné sur le JSON réel. Vérifié aussi par le test backend `rate_limited_relays_to_dto_and_wire` qui asserte `json[\"resetsAtMs\"]`.\n\nCommande Tauri `cancel_resume` (commands.rs:1381) : signature `cancel_resume(agent_id: String) -> Result<bool, _>` — argument **nu** `agentId` (PAS d'enveloppe `{ request }` contrairement à interrupt_agent/delegation_delivered). Adapter aligné en conséquence. Renvoie `true` ssi une reprise était armée et a été désarmée.\n\n## Fichiers modifiés\n1. `frontend/src/domain/index.ts` — 5 variantes ajoutées au union `DomainEvent` (mêmes `type` que le wire, champs exacts `resetsAtMs?`/`fireAtMs`).\n2. `frontend/src/ports/index.ts` — `cancelResume(agentId: string): Promise<boolean>` ajouté à `InputGateway` (port choisi : c'est le gateway des contrôles agent hors-bande, cohérent avec `interrupt`).\n3. `frontend/src/adapters/input.ts` — `TauriInputGateway.cancelResume` → `invoke(\"cancel_resume\", { agentId })` (arg nu, typé `<boolean>`).\n4. `frontend/src/adapters/mock/index.ts` — `MockInputGateway.cancelResume` : enregistre dans `cancelledResumes: string[]`, renvoie `cancelResumeResult` (défaut `true`, flippable par les tests).\n5. `frontend/src/features/agents/useAgents.ts` — état `limitByAgent: Record<string, AgentLimitState>` (interface exportée `{ limitedUntil?, resumeFireAt?, suspected? }`), peuplé depuis les 5 events dans l'abonnement `onDomainEvent` existant (même patron que `delegationSourceByRequester`) :\n   - `agentRateLimited` → `{ limitedUntil: resetsAtMs, suspected: false }` (conserve un `resumeFireAt` éventuel).\n   - `agentResumeScheduled` → arme `resumeFireAt = fireAtMs`.\n   - `agentResumeCancelled` → retire `resumeFireAt`, reste limité.\n   - `agentResumed` → supprime l'entrée (efface tout).\n   - `agentRateLimitSuspected` → `{ limitedUntil: resetsAtMs, suspected: true }`.\n   - Action `cancelResume(agentId)` exposée : retrait optimiste du compte à rebours + appel `input.cancelResume`, renvoie le verdict backend.\n\n## Fichier créé\n6. `frontend/src/features/agents/AgentLimitBadge.tsx` — composant présentational + 2 helpers purs exportés (`formatResetTime(epochMs)` → `HH:MM`, `formatCountdown(remainingMs)` → `Xm Ys`/`Ys`, clampé à 0). Badge « limité jusqu'à HH:MM » / « limité », compte à rebours vivant (clock locale 1 s armée seulement si `resumeFireAt`), bouton « Annuler la reprise ». Câblé dans `AgentsPanel.tsx` (import + rendu conditionnel sous chaque ligne d'agent quand `vm.limitByAgent[a.id]` existe).\n\n## Point de friction — filet humain niveau 3 (§21.1)\nConformément à la consigne, je n'ai **fabriqué aucune commande inexistante**. Le seul point d'entrée backend disponible est `cancel_resume` ; **il n'existe pas de commande pour enregistrer une heure de reprise saisie par l'utilisateur**. Donc pour `agentRateLimitSuspected` sans `resetsAtMs`, le badge affiche l'état « limité · heure inconnue — reprise à préciser » (état + `role=\"note\"`), sans formulaire de saisie. Un `TODO(LS-front)` documenté est posé dans `AgentLimitBadge.tsx` : câbler un formulaire d'heure dès que le backend exposera une commande pour persister l'instant choisi. Si tu veux ce filet pleinement fonctionnel, il faut une tâche backend (ex. `set_resume_at(agentId, epochMs)`) à cadrer avec Architect/DevBackend — je m'y connecterai côté front.\n\nPrêt pour QA (logique d'état dans le hook + helpers purs isolés du JSX, mocks en place avec `cancelledResumes`/`cancelResumeResult`)."}
+{"id":"f21219de-033a-4b3e-8e8b-366534112a95","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781676945137,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Deux livrables distincts sur `feature/agent-session-limits` (Git en fera 2 commits séparés — ne commit pas toi-même).\n\n═══ LIVRABLE 1 — LS8-front : formulaire de saisie d'heure (filet humain niveau 3) ═══\nLe backend expose maintenant une commande Tauri `set_resume_at(agentId: string, resetsAtMs: number) -> void` (argument nu `{ agentId, resetsAtMs }`, comme `cancel_resume`). Elle arme la MÊME reprise annulable que l'auto et réémet `agentResumeScheduled` — donc une fois appelée, ton badge bascule TOUT SEUL de « heure inconnue » vers l'état nominal « limité jusqu'à HH:MM » + compte à rebours + bouton Annuler (déjà câblés en LS7). Aucun nouvel événement à consommer.\n\nÀ FAIRE :\n1. Port : ajoute `setResumeAt(agentId: string, resetsAtMs: number): Promise<void>` à `InputGateway` (`src/ports/index.ts`), à côté de `cancelResume`.\n2. Adapter Tauri (`src/adapters/input.ts`) : `setResumeAt` → `invoke(\"set_resume_at\", { agentId, resetsAtMs })`.\n3. Mock (`src/adapters/mock/index.ts`) : `MockInputGateway.setResumeAt` enregistre dans un tableau (ex. `resumeArmings: { agentId, resetsAtMs }[]`) pour les tests ; suis le patron de `cancelledResumes`.\n4. Hook `useAgents` : expose une action `setResumeAt(agentId, resetsAtMs)` qui délègue au port (pas de mutation optimiste nécessaire — l'event `agentResumeScheduled` rebasculera l'état). \n5. UI `AgentLimitBadge.tsx` : sur l'état SUSPECTED SANS heure (`suspected === true` && pas de `limitedUntil`/`resumeFireAt`), remplace le TODO/placeholder par un petit formulaire : un input heure (type `time` ou `datetime-local`) + bouton « Programmer la reprise ». À la soumission : convertir la saisie en epoch-ms (si input `time` seul = aujourd'hui à HH:MM ; si déjà passé dans la journée, le backend clampe à maintenant ⇒ reprise immédiate, donc pas besoin de validation stricte côté front, mais documente le comportement). Appeler l'action `setResumeAt(agentId, epochMs)`. Garde un helper pur exporté pour la conversion (ex. `timeInputToEpochMs(value, now)`) pour la testabilité. Style cohérent avec le reste du badge ; désactive pendant `busy`.\n6. Retire le `TODO(LS-front)` posé en LS7 (le filet est maintenant complet).\n\n═══ LIVRABLE 2 — fix test préexistant (hygiène, commit séparé) ═══\n`src/adapters/mock/mock.test.ts:16` asserte « thirteen gateways » mais il y en a 14 (la gateway `permission` existe déjà dans HEAD). Mets le compteur à jour (14, et le libellé texte si présent) pour que `npx vitest run src/adapters/mock/` repasse vert. NE change RIEN d'autre dans ce fichier ; vérifie juste que le compte réel est bien 14 avant de figer le nombre.\n\nLance `npx vitest run src/features/agents/ src/adapters/mock/` + `tsc --noEmit` et RENDS-MOI via idea_reply : fichiers modifiés/créés par livrable, le helper de conversion exact, le résultat des deux commandes (typecheck + tests), et le nombre réel de gateways constaté. Structure pour testabilité (logique dans le hook + helpers purs). NE COMMIT PAS — Git tranche, en 2 commits séparés (LS8-front / fix-test)."}
+{"id":"50c3e999-c6a3-4d8b-aef3-b6c273ed9afc","conversation":"09b15ec3-ce2f-0af2-2903-ef699df9de41","atMs":1781677152871,"source":{"kind":"agent","agentId":"af7f86da-76bc-48e1-9900-71f45a624800"},"role":"response","text":"Les deux livrables sont prêts. NON commité (Git tranche, 2 commits séparés).\n\n## Résultats des commandes\n- `npx tsc --noEmit` : **propre** (0 erreur).\n- `npx vitest run src/features/agents/ src/adapters/mock/` : **109 tests / 8 fichiers, tous verts**.\n\n## Nombre réel de gateways constaté : **14**\nLe `Gateways` (ports/index.ts) en a 14 ; l'array du test en listait 13 — il manquait `permission` (présente dans HEAD). Compteur + libellé + array corrigés.\n\n## Helper de conversion exact (pur, exporté, testé)\n```ts\n// AgentLimitBadge.tsx\nexport function timeInputToEpochMs(value: string, now: number): number | null {\n  const match = /^(\\d{1,2}):(\\d{2})$/.exec(value.trim());\n  if (!match) return null;\n  const hours = Number(match[1]);\n  const minutes = Number(match[2]);\n  if (hours > 23 || minutes > 59) return null;\n  const d = new Date(now);\n  d.setHours(hours, minutes, 0, 0);\n  return d.getTime();\n}\n```\nComportement documenté : input `time` seul ⇒ aujourd'hui à HH:MM (même jour calendaire que `now`). Une heure déjà passée renvoie un instant < now **sans validation stricte** — le backend clampe à maintenant ⇒ reprise immédiate (commenté dans le code et couvert par un test). Empty/malformé/`25:00`/`12:60` ⇒ `null` (saisie incomplète ignorée).\n\n═══ LIVRABLE 1 — LS8-front (commit « LS8-front ») ═══\nFichiers modifiés :\n1. `frontend/src/ports/index.ts` — `setResumeAt(agentId, resetsAtMs): Promise<void>` ajouté à `InputGateway`, à côté de `cancelResume`.\n2. `frontend/src/adapters/input.ts` — `setResumeAt` → `invoke(\"set_resume_at\", { agentId, resetsAtMs })` (args nus, comme cancel_resume).\n3. `frontend/src/adapters/mock/index.ts` — `MockInputGateway.setResumeAt` enregistre dans `resumeArmings: { agentId, resetsAtMs }[]` (patron `cancelledResumes`).\n4. `frontend/src/features/agents/useAgents.ts` — action `setResumeAt(agentId, resetsAtMs)` exposée, délègue au port, **aucune mutation optimiste** (l'event `agentResumeScheduled` rebascule l'état via l'abonnement existant).\n5. `frontend/src/features/agents/AgentLimitBadge.tsx` — état SUSPECTED sans heure (`suspected===true && !limitedUntil && !resumeFireAt`) : le placeholder/TODO LS7 est remplacé par un **formulaire** (input `type=\"time\"` aria-label `resume time` + bouton `Programmer la reprise` aria-label `schedule resume`, désactivés pendant `busy`/saisie vide). Soumission → `timeInputToEpochMs` → `onSetResumeAt(epochMs)`. Une fois armé, le badge bascule **tout seul** vers « limité jusqu'à HH:MM » + compte à rebours + Annuler (chaîne LS7 inchangée). TODO(LS-front) **retiré**.\n6. `frontend/src/features/agents/AgentsPanel.tsx` — passe `onSetResumeAt={(ms) => void vm.setResumeAt(a.id, ms)}` au badge.\n7. `frontend/src/features/agents/AgentLimitBadge.test.tsx` — **test QA préexistant (LS7) mis à jour au nouveau contrat** (prop requise `onSetResumeAt`, le cas « suspected sans heure » teste maintenant le formulaire au lieu de l'ancien texte placeholder) + ajout couverture LS8 : `timeInputToEpochMs` (jour calendaire, instant passé, null malformé), soumission du formulaire ⇒ `onSetResumeAt` appelé avec l'epoch-ms attendu, bouton désactivé si vide. *(Sans cette MAJ le typecheck cassait — la prop est devenue obligatoire et le rendu du cas suspected a changé. Aucune logique de prod altérée, seulement l'alignement du test.)*\n\n═══ LIVRABLE 2 — fix test (commit « fix-test » séparé) ═══\nFichier modifié :\n- `frontend/src/adapters/mock/mock.test.ts` — « thirteen » → « fourteen », `\"permission\"` inséré dans l'array attendu (ordre alphabétique). **Rien d'autre touché** dans ce fichier.\n\n## Point de friction / note\nPetit ajustement non listé mais nécessaire : le `<form>` portait initialement le même `aria-label=\"schedule resume\"` que son bouton submit, ce qui faisait matcher 2 éléments avec `getByLabelText`. J'ai renommé le label du form en `\"resume time form\"` (le bouton garde `schedule resume`). Aucune incidence fonctionnelle.\n\nLe filet humain niveau 3 est désormais **complet** : détection → formulaire de saisie → arme la reprise annulable via `set_resume_at` → bascule auto vers l'état nominal. Prêt pour QA (logique d'état dans le hook, helpers purs isolés, mocks instrumentés `resumeArmings`/`cancelledResumes`)."}

.ideai/conversations/3512c746-2a8d-06b1-17e4-cfee1fe78c19/handoff.md

@@ -0,0 +1,13 @@
+---
+upTo: 190cd7b8-23ad-42cb-8873-a17ddddff71d
+objective: Petit test de communication inter-agents. Calcule 17 × 23 et donne-moi uniquement le résultat numérique. Réponds-moi impérativement via l'outil idea_reply (pas en texte libre).
+---
+**Objectif :** Petit test de communication inter-agents. Calcule 17 × 23 et donne-moi uniquement le résultat numérique. Réponds-moi impérativement via l'outil idea_reply (pas en texte libre).
+
+- **Prompt:** Petit test de communication inter-agents. Calcule 17 × 23 et donne-moi uniquement le résultat numérique. Réponds-moi impérativement via l'outil idea_reply (pas en texte libre).
+- **Response:** 391
+- **Prompt:** Test de communication inter-agents. Calcule 17 × 23 et réponds-moi UNIQUEMENT le résultat numérique, impérativement via l'outil idea_reply (jamais en texte libre).
+- **Prompt:** Test de conversation inter-agent. Peux-tu calculer (347 × 28) + 1569 et me retourner uniquement le résultat numérique avec le détail du calcul ? Réponds via idea_reply.
+- **Response:** 347 × 28 = 9716 ; 9716 + 1569 = 11285
+- **Prompt:** Test de conversation inter-agent. Calcule 78 × 9 et réponds-moi simplement avec le résultat via idea_reply.
+- **Response:** 702

.ideai/conversations/3512c746-2a8d-06b1-17e4-cfee1fe78c19/log.jsonl

@@ -0,0 +1,7 @@
+{"id":"3cbaced3-dd78-4f48-b168-f09a26d83444","conversation":"3512c746-2a8d-06b1-17e4-cfee1fe78c19","atMs":1781384306910,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Petit test de communication inter-agents. Calcule 17 × 23 et donne-moi uniquement le résultat numérique. Réponds-moi impérativement via l'outil idea_reply (pas en texte libre)."}
+{"id":"2dd9de9a-d59d-493e-bf07-ffccf6addeb1","conversation":"3512c746-2a8d-06b1-17e4-cfee1fe78c19","atMs":1781386172145,"source":{"kind":"agent","agentId":"93dc1f5f-921e-44a2-a7e7-5173d87c1a58"},"role":"response","text":"391"}
+{"id":"34916afd-1054-4257-805f-9c5b3ed5f7f3","conversation":"3512c746-2a8d-06b1-17e4-cfee1fe78c19","atMs":1781386172204,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Test de communication inter-agents. Calcule 17 × 23 et réponds-moi UNIQUEMENT le résultat numérique, impérativement via l'outil idea_reply (jamais en texte libre)."}
+{"id":"6e037034-c65a-4eca-b494-06420c5eed06","conversation":"3512c746-2a8d-06b1-17e4-cfee1fe78c19","atMs":1781386464926,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Test de conversation inter-agent. Peux-tu calculer (347 × 28) + 1569 et me retourner uniquement le résultat numérique avec le détail du calcul ? Réponds via idea_reply."}
+{"id":"f82caa94-daba-4171-aa1f-8f69f71671c4","conversation":"3512c746-2a8d-06b1-17e4-cfee1fe78c19","atMs":1781386489560,"source":{"kind":"agent","agentId":"93dc1f5f-921e-44a2-a7e7-5173d87c1a58"},"role":"response","text":"347 × 28 = 9716 ; 9716 + 1569 = 11285"}
+{"id":"6187c292-4d9a-4c07-9381-732486ab6d03","conversation":"3512c746-2a8d-06b1-17e4-cfee1fe78c19","atMs":1781522784017,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Test de conversation inter-agent. Calcule 78 × 9 et réponds-moi simplement avec le résultat via idea_reply."}
+{"id":"190cd7b8-23ad-42cb-8873-a17ddddff71d","conversation":"3512c746-2a8d-06b1-17e4-cfee1fe78c19","atMs":1781522789866,"source":{"kind":"agent","agentId":"93dc1f5f-921e-44a2-a7e7-5173d87c1a58"},"role":"response","text":"702"}

.ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/handoff.md

@@ -0,0 +1,26 @@
+---
+upTo: 6df9f7b7-fcc4-4b87-94db-33dce2d76f13
+objective: Nouvelle feature cadrée par Architect, prête à démarrer le développement : « Gestion des limites de session des agents » (détection hiérarchique des limites de session + reprise auto annulable). C'est
+---
+**Objectif :** Nouvelle feature cadrée par Architect, prête à démarrer le développement : « Gestion des limites de session des agents » (détection hiérarchique des limites de session + reprise auto annulable). C'est
+
+- **Response:** Décision (agent Git) — branche retenue : **`feature/agent-session-limits`**, créée **depuis `develop`**. **Raisonnement :** - Nouvelle feature indépendante (LS1→LS8) → conformément au modèle `main ← develop ← feature/*`, elle se développe sur sa propre branche `feature/*`. - Pas besoin de (re)créer `develop` : il existe déjà et est à jour (post-release 0.1.0, `git diff main develop` vide → contenu identique). C'est donc la bonne base de départ. - Nom dérivé du sujet, kebab-case : `feature/agent-session-limits`. **État git après manœuvre (LOCAL, aucun push) :** - Branche courante : `feature/agent-session-limits` @ `401c18a` (= base `develop`). - `develop` @ `401c18a` (inchangé) ← `main` @ `9a8a89f` (tag `v0.1.0`, inchangé). - `feature/agent-skills` @ `ef101db` (autre feature, intacte). **Note :** le working tree porte déjà des changements non commités hérités de l'état courant — notamment `ARCHITECTURE.md` (cadrage Architect) et un nouveau `.ideai/memory/session-limit-handling-design.md`, plus du runtime `.ideai/` (conversations/MEMORY.md). Ils n'ont pas été commités : DevBackend/QA les intégreront dans les commits de la feature au fil des lots. Le cadrage Architect (ARCHITECTURE.md + memory design) pourra faire le **premier commit** de la branche avant LS1 si tu le souhaites — dis-moi si tu veux que je le commite maintenant. Dev peut démarrer LS1 (domaine) sur `feature/agent-session-limits`. Après chaque lot vert, reviens vers moi pour décider d'un éventuel commit/merge. Aucune intégration vers `develop` tant que les tests des lots concernés ne sont pas verts (règle d'or).
+- **Prompt:** Feu vert pour le premier commit de la branche feature/agent-session-limits : commite le cadrage AVANT que le dev (LS1) ne démarre, pour isoler proprement le cadrage du code. Contenu à committer (cadrage uniquement) : ARCHITECTURE.md (nouvelle §21) + .ideai/memory/session-limit-handling-design.md + la mise à jour de .ideai/memory/MEMORY.md (pointeur). N'inclus PAS le runtime .ideai/ non pertinent (conversations, layouts, agents.json…) s'il pollue le diff — limite le commit aux fichiers du cadrage. Message de commit conforme au style du dépôt (français, conventionnel). Périmètre LOCAL uniquement — aucun push. Confirme le hash du commit et l'état git après.
+- **Response:** Cadrage committé sur `feature/agent-session-limits` — premier commit de la branche, isolé du code. **Commit : `fa5b826`** `docs(session-limits): cadrage Architect — gestion des limites de session des agents` **Contenu (cadrage uniquement, 3 fichiers / +212 lignes) :** - `ARCHITECTURE.md` (+185, nouvelle §21) - `.ideai/memory/session-limit-handling-design.md` (nouveau, design validé) - `.ideai/memory/MEMORY.md` (+1, pointeur) Le runtime `.ideai/` non pertinent (conversations, layouts, agents.json…) a été **exclu** du diff comme demandé. **État git après commit (LOCAL, aucun push) :** - `feature/agent-session-limits` @ `fa5b826` ← `develop` @ `401c18a` ← `main` @ `9a8a89f` (tag `v0.1.0`). - Working tree : reste uniquement du runtime `.ideai/conversations/…` non commité (bruit, ignoré pour le cadrage). La branche est prête : le dev peut démarrer **LS1 (domaine)**. Je reviendrai dans la boucle pour committer chaque lot vert.
+- **Prompt:** LS1 (couche domaine) de la feature « limites de session » est VERT : DevBackend a livré le code pur, QA a écrit 24 tests, `cargo test -p domain` = 165 passed / 0 failed, zéro régression. Commite LS1 sur feature/agent-session-limits (commit suivant après le cadrage fa5b826). Périmètre LOCAL uniquement, aucun push. Fichiers de prod (domaine) modifiés/créés par DevBackend : - crates/domain/src/ports.rs (variante ReplyEvent::RateLimited) - crates/domain/src/readiness.rs (variante ReadinessSignal::RateLimited + classify) - crates/domain/src/session_limit.rs (NOUVEAU : SessionLimit, ResumePlan, RateLimitSource, plan_resume) - crates/domain/src/profile.rs (RateLimitPattern + champ + builder) - crates/domain/src/events.rs (5 variantes DomainEvent) - crates/domain/src/lib.rs (mod + re-exports) Plus les tests QA dans ces mêmes fichiers (#[cfg(test)]). N'inclus PAS le runtime .ideai/ non pertinent. Message conventionnel en français. IMPORTANT — décision de merge : NE merge PAS vers develop maintenant. Le workspace complet (`cargo build --workspace`) NE COMPILE PAS tant que LS2 n'a pas ajouté l'arm `ReplyEvent::RateLimited` côté infra (match exhaustifs). On ne merge feature/* → develop que sur une tranche qui compile de bout en bout (cible : LS1+LS2+LS4 = niveau 1 Claude complet). Confirme juste le hash du commit LS1 et l'état git.
+- **Response:** LS1 (couche domaine) committé sur `feature/agent-session-limits`, après le cadrage `fa5b826`. **Commit : `0bf1eb3`** `feat(session-limits): LS1 — couche domaine (détection + plan de reprise)` **Contenu (6 fichiers domaine, prod + tests inline / +647 lignes) :** - `crates/domain/src/session_limit.rs` (nouveau) - `crates/domain/src/ports.rs` (ReplyEvent::RateLimited) - `crates/domain/src/readiness.rs` (ReadinessSignal::RateLimited + classify) - `crates/domain/src/profile.rs` (RateLimitPattern + champ + builder) - `crates/domain/src/events.rs` (5 variantes DomainEvent) - `crates/domain/src/lib.rs` (mod + re-exports) Runtime `.ideai/` non pertinent **exclu**. QA : `cargo test -p domain` = 165 passed / 0 failed, zéro régression. **Décision de merge : PAS de merge vers `develop`** — conforme à ta consigne. Le workspace ne compile pas tant que LS2 n'a pas ajouté l'arm `ReplyEvent::RateLimited` côté infra (match exhaustifs). On n'intègre `feature/* → develop` que sur une tranche qui compile de bout en bout (cible : LS1+LS2+LS4 = niveau 1 Claude complet). Je reste sur la branche feature. **État git (LOCAL, aucun push) :** ``` feature/agent-session-limits @ 0bf1eb3 (HEAD) └ fa5b826 docs cadrage └ 401c18a (develop) ← main @ 9a8a89f (tag v0.1.0) ``` Working tree : seul du runtime `.ideai/conversations/…` non commité (ignoré). Dev peut enchaîner sur LS2.
+- **Prompt:** LS2 (adapter Claude niveau 1, infra) est VERT : `cargo test -p infrastructure` = 188 passed / 0 failed, zéro régression. Commite LS2 sur feature/agent-session-limits (après LS1 0bf1eb3). LOCAL uniquement, aucun push. Fichier de prod modifié : crates/infrastructure/src/session/claude.rs (parse_event émet ReplyEvent::RateLimited ; nouvelle fonction pure parse_reset_ms + helpers ; parseur ISO maison ; doccomments T4). Tests QA : dans crates/infrastructure/src/session/mod.rs (#[cfg(test)]) — 26 nouveaux tests + 2 tests existants mis à jour vers le nouveau contrat ; et crates/infrastructure/src/session/conformance.rs (#[cfg(test)] : RateLimited ajouté aux événements non terminaux autorisés). Exclu le runtime .ideai/. Message conventionnel français. Décision merge : TOUJOURS PAS de merge vers develop (le workspace ne compile pas encore — 2 erreurs résiduelles attendues dans app-tauri, relèvent de LS7/LS8 ; et la réconciliation T4 reste à faire en LS4). On vise la tranche LS1+LS2+LS3+LS4 = niveau 1 Claude de bout en bout qui compile, pour le premier merge. Confirme le hash LS2 et l'état git.
+- **Response:** LS2 (adapter Claude niveau 1, infra) committé sur `feature/agent-session-limits`, après LS1 `0bf1eb3`. **Commit : `a1755e5`** `feat(session-limits): LS2 — adapter Claude niveau 1 (infra)` **Contenu (3 fichiers infra, prod + tests inline / +545 lignes) :** - `crates/infrastructure/src/session/claude.rs` (prod : parse_event → ReplyEvent::RateLimited, parse_reset_ms + helpers, parseur ISO maison, doccomments T4) - `crates/infrastructure/src/session/mod.rs` (26 nouveaux tests QA + 2 alignés) - `crates/infrastructure/src/session/conformance.rs` (RateLimited en non-terminal autorisé) Runtime `.ideai/` **exclu**. QA : `cargo test -p infrastructure` = 188 passed / 0 failed, zéro régression. **Décision de merge : TOUJOURS PAS de merge vers `develop`** — conforme. Le workspace ne compile pas encore (2 erreurs résiduelles attendues dans app-tauri → LS7/LS8 ; réconciliation T4 → LS4). Premier merge visé sur la tranche **LS1+LS2+LS3+LS4 = niveau 1 Claude de bout en bout qui compile**. **État git (LOCAL, aucun push) :** ``` feature/agent-session-limits @ a1755e5 (HEAD) └ 0bf1eb3 LS1 domaine └ fa5b826 cadrage └ 401c18a (develop) ← main @ 9a8a89f (tag v0.1.0) ``` Working tree : seul du runtime `.ideai/` non commité (ignoré). Dev peut enchaîner sur LS3.
+- **Prompt:** LS3 (port Scheduler + adapter TokioScheduler) est VERT : `cargo test -p infrastructure` = 195 passed / 0 failed (7 nouveaux tests scheduler, relancés 3× sans flaky), LS1/LS2 toujours verts. Builds domaine + infra OK 0 warning. Le workspace complet ne compile toujours pas (2 erreurs résiduelles inchangées dans app-tauri : chat.rs:185 → LS8, events.rs:261 → LS7 ; la réconciliation T4 reste en LS4). C'est TOI qui décides quoi et quand committer/merger. Je te livre l'état, tu tranches. Fichiers de prod LS3 : - crates/domain/src/ids.rs (ScheduleId via typed_id!) - crates/domain/src/ports.rs (trait Scheduler + enum ScheduledTask) - crates/domain/src/lib.rs (re-exports) - crates/infrastructure/src/scheduler/mod.rs (NOUVEAU : TokioScheduler) - crates/infrastructure/src/lib.rs (pub mod scheduler + re-export) Tests QA : dans crates/infrastructure/src/scheduler/mod.rs (#[cfg(test)]). Runtime .ideai/ à exclure du diff. Décide : faut-il committer LS3 maintenant (et avec quel message) ? Et concernant le merge vers develop — rappel du contexte : le premier merge envisagé portait sur la tranche LS1+LS2+LS3+LS4 (niveau 1 Claude de bout en bout qui compile), or le workspace ne compile pas encore (LS4 + app-tauri manquants). Dis-moi ta décision (commit LS3 sur la feature ? attendre la tranche compilable pour merger ? autre ?) et exécute-la. Confirme hash + état git.
+- **Response:** Décision (agent Git) : **commit LS3 sur la feature, PAS de merge vers `develop`.** **Pourquoi :** chaque lot vert mérite son commit atomique sur la branche feature (traçabilité, bissection facile), mais le merge `feature/* → develop` exige une tranche qui **compile de bout en bout** — règle d'or. Or le workspace ne compile toujours pas (réconciliation T4 en LS4 + 2 erreurs résiduelles app-tauri : `chat.rs:185`→LS8, `events.rs:261`→LS7). Donc on continue d'accumuler sur la feature ; premier merge maintenu sur la tranche compilable (LS1+LS2+LS3+LS4 niveau 1 Claude, voire jusqu'à LS7/LS8 si la compilation workspace n'est verte qu'à ce moment-là). **Commit : `253310b`** `feat(session-limits): LS3 — port Scheduler + adapter TokioScheduler` **Contenu (5 fichiers prod + tests inline / +389 lignes) :** - domaine : `ports.rs` (trait Scheduler + enum ScheduledTask), `ids.rs` (ScheduleId), `lib.rs` (re-exports) - infra : `scheduler/mod.rs` (nouveau, TokioScheduler), `lib.rs` (pub mod + re-export) Runtime `.ideai/` **exclu**. QA : `cargo test -p infrastructure` = 195 passed / 0 failed (7 tests scheduler, 3× sans flaky) ; LS1/LS2 verts ; builds domaine+infra 0 warning. **État git (LOCAL, aucun push) :** ``` feature/agent-session-limits @ 253310b (HEAD) └ a1755e5 LS2 adapter Claude └ 0bf1eb3 LS1 domaine └ fa5b826 cadrage └ 401c18a (develop) ← main @ 9a8a89f (tag v0.1.0) ``` Dev peut enchaîner sur LS4 (service application + réconciliation T4). Je tranche le merge dès que le workspace compile.
+- **Prompt:** LS4 (couche application : SessionLimitService + réconciliation T4) est VERT : `cargo test -p application` = tous binaires verts / 0 failed (16 nouveaux tests), zéro régression confirmée (drain_with_readiness_lot1 7/7, send_blocking_d1 9/9, reste du crate vert). Builds domaine+infra+application 0 warning. Le workspace complet ne compile TOUJOURS pas (inchangé : app-tauri chat.rs:185 → LS8, events.rs:261 → LS7). C'est toi qui décides quoi/quand committer/merger. État livré : Fichiers de prod LS4 : - crates/application/src/agent/session_limit.rs (NOUVEAU : SessionLimitService + port AgentResumer + const RESUME_PROMPT) - crates/application/src/agent/structured.rs (réconciliation T4 : enum TurnOutcome + drain_with_readiness_outcome ; signatures historiques préservées) - crates/application/src/agent/mod.rs (mod + re-exports) - crates/application/src/lib.rs (re-exports) Tests QA : crates/application/tests/session_limit_service.rs (9) + crates/application/tests/session_limit_t4.rs (7) (NOUVEAUX). Runtime .ideai/ à exclure. Décide et exécute (commit LS4 sur la feature ? message ? merge ou pas ?). Pour mémoire : le workspace ne compile de bout en bout qu'après LS7 (events app-tauri) + LS8 (chat.rs) ; le premier merge vers develop reste donc subordonné à ta règle d'or « tranche qui compile ». Confirme hash + état git.
+- **Response:** Décision (agent Git) : **commit LS4 sur la feature, PAS de merge vers `develop`.** **Commit : `9000b4d`** `feat(session-limits): LS4 — service application + réconciliation T4` **Contenu (6 fichiers, 4 prod + 2 tests / +987 lignes) :** - `crates/application/src/agent/session_limit.rs` (nouveau : SessionLimitService + port AgentResumer + RESUME_PROMPT) - `crates/application/src/agent/structured.rs` (T4 : enum TurnOutcome + drain_with_readiness_outcome, signatures historiques préservées) - `crates/application/src/agent/mod.rs` + `crates/application/src/lib.rs` (modules/re-exports) - `crates/application/tests/session_limit_service.rs` (9) + `crates/application/tests/session_limit_t4.rs` (7) — nouveaux Runtime `.ideai/` **exclu**. QA : `cargo test -p application` tous binaires verts / 0 failed (16 nouveaux) ; zéro régression (drain_with_readiness_lot1 7/7, send_blocking_d1 9/9) ; builds domaine+infra+application 0 warning. **Décision de merge : toujours NON.** La tranche LS1→LS4 est verte par crate, mais `cargo build --workspace` échoue encore (app-tauri : `chat.rs:185`→LS8, `events.rs:261`→LS7). Ma règle d'or impose une tranche qui **compile de bout en bout** avant tout `feature/* → develop`. Comme tu me l'as confirmé, le workspace ne sera vert qu'après LS7+LS8 → **le premier merge se fera donc sur LS1→LS8** (et non LS1→LS4 comme envisagé initialement). On accumule jusque-là sur la branche feature. **État git (LOCAL, aucun push) :** ``` feature/agent-session-limits @ 9000b4d (HEAD) └ 253310b LS3 · a1755e5 LS2 · 0bf1eb3 LS1 · fa5b826 cadrage └ 401c18a (develop) ← main @ 9a8a89f (tag v0.1.0) ``` Dev peut enchaîner sur LS5 (parser regex). Je tranche le merge dès `cargo build --workspace` vert.
+- **Prompt:** LS5 (parser regex niveau 2, infra) est VERT : `cargo test -p infrastructure` = 221 passed / 0 failed (26 nouveaux), 0 warning, LS2/LS3 toujours verts (refactor timeparse non régressif). C'est toi qui décides commit/merge. Fichiers de prod LS5 : - crates/infrastructure/Cargo.toml (dépendance regex = "1", résout 1.12.3 déjà dans Cargo.lock) - crates/infrastructure/src/ratelimit/mod.rs (NOUVEAU : RateLimitParser + applies) - crates/infrastructure/src/timeparse.rs (NOUVEAU : parsing d'heure pur partagé, factorisé depuis LS2) - crates/infrastructure/src/session/claude.rs (délègue à timeparse — refactor) - crates/infrastructure/src/lib.rs (pub mod ratelimit + timeparse, re-export) Modifs de TEST QA : crates/infrastructure/src/ratelimit/mod.rs (#[cfg(test)] 15 tests), crates/infrastructure/src/timeparse.rs (#[cfg(test)] 11 tests), crates/infrastructure/src/scheduler/mod.rs (2 warnings irrefutable if let corrigés dans le code de test). NOTE : Cargo.lock peut être inchangé (regex déjà verrouillée) — inclus-le seulement s'il bouge. Runtime .ideai/ à exclure. Décide et exécute (commit LS5 ? message ? merge ?). Pour mémoire le workspace ne compile de bout en bout qu'après LS7+LS8. Confirme hash + état git.
+- **Prompt:** Feature session-limits, suite. Project root: /home/anthony/Documents/Projects/IdeA. Deux lots sont terminés et VERTS (workspace compile, `cargo test --workspace` tout vert, clippy propre sur le nouveau code) mais NON committés : - LS5 — détecteur niveau 2 déclaratif + parsing temps partagé. Fichiers : nouveau `crates/infrastructure/src/ratelimit/mod.rs` (RateLimitParser, regex confiné infra), nouveau `crates/infrastructure/src/timeparse.rs` (parsing d'heures pur, partagé niveau 1/2), modifs `crates/infrastructure/src/session/claude.rs` (refactor vers timeparse, ~-121 lignes), `crates/infrastructure/src/scheduler/mod.rs`, `crates/infrastructure/src/lib.rs` (exports), `crates/infrastructure/Cargo.toml` (dép `regex`), `Cargo.lock`. - LS6 — câblage des 5 nouvelles variantes DomainEvent (AgentRateLimited/ResumeScheduled/ResumeCancelled/Resumed/RateLimitSuspected) + ReplyEvent::RateLimited vers le front. Fichiers : `crates/app-tauri/src/events.rs` (DTO miroir + bras From + test relais), `crates/app-tauri/src/chat.rs` (chunk_from_event). Note : l'arbre contient aussi des fichiers runtime .ideai/ modifiés (conversations/*/handoff.md, log.jsonl, layouts.json, memory/) et un nouveau memory `git-owns-commit-merge-decisions.md` — à toi de juger ce qui entre ou non dans le(s) commit(s) applicatif(s) (rappel : les LS précédents committaient uniquement le code applicatif, pas le bruit runtime). La branche courante est détachée (HEAD), pas sur develop. À toi de décider : topologie de branche, découpage en un ou deux commits (LS5 puis LS6, ou groupés), messages dans le style des commits feat(session-limits) existants, et si un merge feature/* → develop doit suivre. Périmètre LOCAL uniquement (aucun push). Exécute ta décision et rends via idea_reply le détail (branche, sha, messages, état final de `git status`).
+- **Response:** Fait. Décisions et exécution : **Branche** — Contrairement à ce qui était annoncé, HEAD n'était pas détachée : on était bien sur `feature/agent-session-limits` (la branche de la feature). Aucune création/bascule nécessaire, le dev se poursuit dessus. Rien à corriger. **Découpage — 2 commits atomiques** (LS5 puis LS6, séparés car deux intentions distinctes : couche infra de détection vs câblage événementiel vers le front) : 1. `98bfcf4` — feat(session-limits): LS5 — détecteur niveau 2 déclaratif + parsing temps partagé Fichiers : `crates/infrastructure/src/ratelimit/mod.rs` (nouv.), `crates/infrastructure/src/timeparse.rs` (nouv.), `crates/infrastructure/src/session/claude.rs`, `crates/infrastructure/src/scheduler/mod.rs`, `crates/infrastructure/src/lib.rs`, `crates/infrastructure/Cargo.toml`, `Cargo.lock`. 2. `ea94e75` — feat(session-limits): LS6 — câblage des événements de limite vers le front Fichiers : `crates/app-tauri/src/events.rs`, `crates/app-tauri/src/chat.rs`. Messages en français, style Conventional Commits cohérent avec LS1→LS4, corps expliquant le pourquoi, co-author inclus. **Bruit runtime exclu** — Non committé, comme pour les LS précédents : `.ideai/conversations/*` (handoff.md, log.jsonl), `.ideai/layouts.json`, `.ideai/memory/` (dont MEMORY.md et le nouveau `git-owns-commit-merge-decisions.md`), et la nouvelle conversation `6bc594e8-…`. Ce sont des artefacts d'exécution, pas du code applicatif. **Merge feature/* → develop : NON.** La feature session-limits est livrée par incréments (série LS en cours) ; LS5/LS6 sont verts mais internes (détecteur niveau 2 + relais d'événements) sans surface produit complète. On reste sur `feature/agent-session-limits`. Le merge vers `develop` se fera quand la feature sera terminée et toujours verte. **Périmètre** — 100% local, aucun push. **État final `git status`** : working tree propre côté applicatif ; ne subsistent que les fichiers runtime `.ideai/` modifiés/non suivis (volontairement hors commit). Derniers commits : ea94e75 LS6 / 98bfcf4 LS5 / 9000b4d LS4.
+- **Prompt:** Slice LS7 (backend / câblage app-tauri) de la feature session-limits terminée et verte. On est sur la branche feature/agent-session-limits (HEAD détaché ? `git status` montre HEAD), dernier commit ea94e75 (LS6). Contenu à committer (tout est vert, aucun warning) : - crates/application/src/agent/lifecycle.rs : `LaunchAgentOutput.profile` exposé (None sur réattache/idempotent, Some sur lancement effectif). - crates/application/src/terminal/registry.rs : `StructuredSessions::meta_for_session()` (lookup agent/node par SessionId pour le tap niveau 1). - crates/app-tauri/src/state.rs : `ResumeContext`/`ResumeContexts`, `AppAgentResumer` (impl port `AgentResumer` au-dessus de LaunchAgent), instanciation+câblage du `SessionLimitService` (TokioScheduler + drain des réveils) dans `AppState::build`. - crates/app-tauri/src/commands.rs : taps niveau 1 (agent_send) et niveau 2 (launch_agent, parser regex confiné), alimentation de `resume_contexts`, nouvelle commande `cancel_resume`. - crates/app-tauri/src/lib.rs : enregistrement de `cancel_resume` dans le handler. - crates/app-tauri/Cargo.toml : dépendance `async-trait`. - crates/app-tauri/tests/session_limit_wiring.rs : 2 tests d'intégration (composition) — verts. - crates/app-tauri/tests/dto_agents.rs + dto_chat.rs : ajustement `profile: None` dans les fixtures. - crates/application/tests/structured_registry_d1.rs : test de `meta_for_session`. Hors périmètre code (à NE PAS committer dans ce commit applicatif) : .ideai/conversations/**, .ideai/layouts.json, .ideai/memory/** — ce sont des artefacts runtime/mémoire. Questions : 1) Faut-il committer cette slice LS7-backend maintenant, et sous quel message ? 2) Reste-t-on sur feature/agent-session-limits ? 3) Décides-tu d'un merge vers develop, ou on attend LS7-front (React/TS, badge + compte à rebours + filet humain) qui complète la surface produit ? Tranche et exécute le commit applicatif si tu juges que oui.
+- **Response:** Décision Git — LS7 backend committée, on reste en feature, pas de merge maintenant. État initial : on était bien **sur la branche** `feature/agent-session-limits` (pas de HEAD détaché — le « HEAD » de ton `git status` était juste l'en-tête francisé), HEAD = ea94e75 (LS6). 1) ✅ Commit fait. Hash **9df5923** : `feat(session-limits): LS7 — câblage backend app-tauri (taps niveaux 1&2 + reprise annulable)` - 10 fichiers, +406/−3, dont la création de `tests/session_limit_wiring.rs`. - Périmètre strictement applicatif : lifecycle.rs, registry.rs, state.rs, commands.rs, lib.rs, Cargo.toml + les 4 fichiers de tests. - **Exclus comme demandé** (restés non-stagés, ce sont des artefacts runtime/mémoire) : `.ideai/conversations/**`, `.ideai/layouts.json`, `.ideai/memory/**` (dont le nouveau `git-owns-commit-merge-decisions.md` et le `6bc594e8…/` non suivi). Commit atomique = code seulement. 2) ✅ On **reste sur `feature/agent-session-limits`**. La feature n'est pas terminée côté produit (il manque LS7-front), donc on continue dessus. 3) ❌ **Pas de merge vers `develop` maintenant.** Raison : la slice est verte mais la surface produit session-limits est **incomplète sans LS7-front** (badge + compte à rebours + filet humain). Merger le backend seul livrerait dans `develop` une mécanique de reprise annulable sans son UI de contrôle/annulation visible — état intermédiaire que je ne veux pas figer dans l'intégration. **On attend LS7-front.** Une fois le front implémenté et la suite complète verte, reviens vers moi : je rebase si besoin sur `develop`, puis merge `--no-ff` la feature entière d'un coup (backend + front cohérents). Prochaine étape côté toi : enchaîner LS7-front (React/TS) sur cette même branche. Quand c'est vert, ping-moi pour le merge d'intégration.
+- **Prompt:** Slice LS7-front (React/TS, UI limites de session) terminée et VERTE sur `feature/agent-session-limits`. État tests : `npx vitest run src/features/agents/` → 4 fichiers, 63 tests passés (39 existants + 24 nouveaux), 0 régression. Typecheck `tsc --noEmit` propre. Fichiers à committer (frontend/ uniquement) : - src/domain/index.ts — 5 variantes ajoutées au union DomainEvent (agentRateLimited/ResumeScheduled/ResumeCancelled/Resumed/RateLimitSuspected). - src/ports/index.ts — `cancelResume(agentId)` ajouté à InputGateway. - src/adapters/input.ts — TauriInputGateway.cancelResume → invoke("cancel_resume", { agentId }). - src/adapters/mock/index.ts — MockInputGateway.cancelResume (cancelledResumes/cancelResumeResult). - src/features/agents/useAgents.ts — état limitByAgent + action cancelResume. - src/features/agents/AgentLimitBadge.tsx — NOUVEAU (badge + compte à rebours + bouton Annuler + helpers purs). - src/features/agents/AgentsPanel.tsx — câblage du badge. - src/features/agents/useAgentsLimits.test.tsx — NOUVEAU (13 tests, QA). - src/features/agents/AgentLimitBadge.test.tsx — NOUVEAU (11 tests, QA). Hors périmètre (NE PAS committer) : .ideai/** (artefacts runtime/mémoire). Aucun fichier backend touché. NOTE : il existe un test PRÉEXISTANT rouge SANS rapport avec cette slice — `src/adapters/mock/mock.test.ts:16` asserte « thirteen gateways » alors qu'il y en a 14 (gateway `permission` déjà présente dans HEAD committé eca2ba9). Compteur périmé, pas causé par LS7-front. À toi de voir si tu veux que je fasse corriger ce compteur (tâche séparée DevFrontend) avant/après — dis-moi. Questions : 1) Committe la slice LS7-front maintenant ? Sous quel message ? 2) Le merge --no-ff de la feature complète vers develop : on attend que je tranche le dernier point de scope (filet humain niveau 3 — voir consultation Architect en cours : peut nécessiter une slice backend+front supplémentaire `set_resume_at`), donc NE merge pas encore vers develop — confirme que tu te limites au commit de cette slice et qu'on garde le merge pour quand je te recontacte « feature complète ». Tranche et exécute le commit.
+- **Response:** Décision Git — LS7-front committée, pas de merge develop (j'attends ton « feature complète »). 1) ✅ Commit fait. Hash **4fad042** : `feat(session-limits): LS7-front — UI limites de session (badge + compte à rebours + filet humain)` - 9 fichiers, +702/−1, dont 3 créations (AgentLimitBadge.tsx + ses 2 fichiers de tests). - Périmètre strictement frontend : domain/index.ts, ports/index.ts, adapters/input.ts, adapters/mock/index.ts, useAgents.ts, AgentLimitBadge.tsx, AgentsPanel.tsx + les 2 tests. - **Exclus comme demandé** (non-stagés) : `.ideai/**` (conversations, layouts, memory) et `node_modules/` (non suivi — au passage, il traîne en untracked ; à gitignorer dans une tâche d'hygiène séparée si ce n'est pas déjà couvert, mais hors périmètre ici). Aucun fichier backend touché. Commit atomique = frontend seulement. 2) ✅ Confirmé : **je me limite à ce commit, pas de merge vers `develop`.** Je garde le `--no-ff` d'intégration de la feature complète pour quand tu me recontactes « feature complète », une fois tranché le scope du filet humain niveau 3 (slice `set_resume_at` éventuelle, cf. consultation Architect). Concernant le **test préexistant rouge** `mock.test.ts:16` (« thirteen gateways » → 14 réelles, gateway `permission` déjà dans HEAD eca2ba9) : compteur périmé sans rapport avec LS7. Mon avis Git : à corriger **avant le merge d'intégration**, en **commit séparé** (`fix(test): …` ou `chore(test): …`), pour ne pas merger `develop` avec une suite rouge. Lance une tâche DevFrontend dédiée quand tu veux ; tu peux l'enchaîner maintenant ou la grouper avec l'éventuelle slice `set_resume_at` — dans tous les cas elle aura son propre commit, et je ne mergerai pas tant que toute la suite n'est pas verte. État branche : `feature/agent-session-limits` → … ea94e75 (LS6) · 9df5923 (LS7 back) · **4fad042 (LS7 front, HEAD)**.
+- **Prompt:** Feature session-limits COMPLÈTE (3 niveaux) et verte. Reste à committer 2 slices, puis on peut envisager le merge d'intégration `feature/agent-session-limits → develop` que tu gardais en attente. État branche actuel : … 9df5923 (LS7 back) · 4fad042 (LS7 front, HEAD). Travail NON committé depuis, à committer maintenant en 2 commits séparés : ═══ COMMIT A — LS8-backend (filet humain niveau 3, backend) ═══ Implémenté par DevBackend, testé par QA (application: 15 tests session_limit_service / app-tauri: 4 wiring, + régressions vertes, 0 failed). Fichiers : - crates/application/src/agent/session_limit.rs — refactor privé `arm_scheduled` (param `resets_at_ms` brut ajouté) partagé par `on_rate_limited` + nouvelle `pub fn confirm_human_resume(agent_id, node_id, conversation_id, resets_at_ms: i64)` (source Human, réutilise la branche Scheduled, annulable). - crates/app-tauri/src/commands.rs — nouvelle commande `set_resume_at(agent_id, resets_at_ms) -> Result<(), ErrorDto>` (résout node_id via node_for_agent + conversation_id best-effort, NOT_FOUND si pas de cellule vivante). - crates/app-tauri/src/lib.rs — `set_resume_at` enregistrée après `cancel_resume`. - crates/application/tests/session_limit_service.rs — +6 tests (QA). - crates/app-tauri/tests/session_limit_wiring.rs — +2 tests (QA). Aucun événement nouveau (réutilise AgentRateLimited + AgentResumeScheduled). ═══ COMMIT B — LS8-front + fix test (DevFrontend a demandé 2 commits ; à toi de voir si tu sépares ou regroupes) ═══ LS8-front (typecheck propre, 109 tests verts) : - frontend/src/ports/index.ts — `setResumeAt(agentId, resetsAtMs)` sur InputGateway. - frontend/src/adapters/input.ts — `setResumeAt` → invoke("set_resume_at", { agentId, resetsAtMs }). - frontend/src/adapters/mock/index.ts — MockInputGateway.setResumeAt (resumeArmings[]). - frontend/src/features/agents/useAgents.ts — action setResumeAt (sans mutation optimiste). - frontend/src/features/agents/AgentLimitBadge.tsx — formulaire de saisie d'heure sur l'état suspected sans heure + helper pur `timeInputToEpochMs` ; TODO LS7 retiré. - frontend/src/features/agents/AgentsPanel.tsx — câblage onSetResumeAt. - frontend/src/features/agents/AgentLimitBadge.test.tsx — tests mis à jour au nouveau contrat + couverture LS8. Fix test hygiène (DevFrontend recommande commit SÉPARÉ) : - frontend/src/adapters/mock/mock.test.ts — compteur gateways 13→14 (« thirteen »→« fourteen » + `permission` dans l'array). Vérifié : 14 gateways réelles. Hors périmètre (NE PAS committer) : .ideai/** (runtime/mémoire), node_modules/ (untracked — DevFrontend signalait qu'il traîne, à gitignorer dans une tâche d'hygiène séparée, hors périmètre ici). QUESTIONS : 1) Committe COMMIT A puis les commits front (LS8-front + fix-test, séparés ou groupés selon ton jugement). Donne-moi les hashes + messages. 2) La suite complète est maintenant verte (Rust: domain/application/app-tauri ; front: agents + adapters/mock 109 tests) et la surface produit session-limits est complète sur les 3 niveaux. Décides-tu MAINTENANT le merge `--no-ff` vers develop (rebase si besoin) ? Si oui, exécute-le et donne-moi le résultat. Si tu veux un dernier garde-fou (ex. run de la suite complète des deux côtés avant merge), dis-le et je le fais lancer.
+- **Response:** ✅ 3 commits + merge d'intégration faits. La feature session-limits est intégrée dans `develop`. ═══ 1) Les 3 commits (sur feature/agent-session-limits) ═══ J'ai séparé le fix-test de la feature (hygiène isolée, comme recommandé par DevFrontend) → 3 commits : - **c480d28** `feat(session-limits): LS8-backend — filet humain niveau 3 (set_resume_at)` (session_limit.rs + commands.rs + lib.rs + tests service/wiring ; 5 fichiers, +394/−18) - **5d9dd32** `feat(session-limits): LS8-front — filet humain niveau 3 (saisie d'heure de reprise)` (ports/input/mock + useAgents + AgentLimitBadge(.tsx/.test) + AgentsPanel ; 7 fichiers, +222/−26) - **3f3504e** `fix(test): corrige le compteur de gateways du mock (13 → 14)` (mock.test.ts isolé ; 1 fichier, +2/−1) Artefacts `.ideai/**` et `node_modules/` exclus comme demandé. ═══ 2) Merge `--no-ff` → develop : OUI, exécuté ═══ Décision : la surface produit est complète sur les 3 niveaux et tout est vert des deux côtés → je merge. Pas de rebase nécessaire : `feature` était **12 ahead / 0 behind** `develop` (aucune divergence, base linéaire). - Merge commit : **d7041c5** `merge(session-limits): intégration de la feature limites de session (3 niveaux)` — stratégie ort, **0 conflit**, 47 fichiers / +5157/−45 (cumul LS2→LS8). - `develop` est maintenant à **d7041c5**, contenant toute la chaîne LS2 (a1755e5) → LS8 (3f3504e). - La branche `feature/agent-session-limits` est **conservée** (pas supprimée) : je la garde tant que tu n'as pas confirmé que l'intégration est définitivement validée. Dis-moi si tu veux que je la supprime maintenant. Note d'exécution : les artefacts runtime `.ideai/**` non committés bloquaient le switch de branche → je les ai **stashés le temps du merge puis restaurés** (stash poppé, working tree intact, rien perdu). Aucun de ces artefacts n'est entré dans les commits applicatifs ni dans le merge. ⚠️ Périmètre **strictement local** : aucun `push`. `develop` local est en avance de 58 commits sur `origin/develop` — je ne pousse rien sans ta validation explicite. Prochaines options possibles, à ta main : suppression de `feature/agent-session-limits`, et/ou push de `develop` vers origin (action sortante → nécessite ton feu vert).

.ideai/conversations/6bc594e8-a37c-0dbd-1de6-6e3b73002cb4/log.jsonl

@@ -0,0 +1,21 @@
+{"id":"28eded2d-7fd7-48cf-bc4a-c38a89ed06e3","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781612485902,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Nouvelle feature cadrée par Architect, prête à démarrer le développement : « Gestion des limites de session des agents » (détection hiérarchique des limites de session + reprise auto annulable). C'est toi qui décides de la topologie de branche — je te sollicite, tu tranches.\n\nContexte dépôt : HEAD actuel sur le commit de release 0.1.0 (9a8a89f « release(0.1.0) : intégration de develop »). Modèle de branches du projet : main (release) ← develop (intégration) ← feature/* (une par feature).\n\nLa feature sera livrée en lots ordonnés LS1→LS8 (domaine → adapter Claude → port Scheduler → service application → parser regex → filet humain → app-tauri → frontend), chacun passant par le cycle dev/test (tests verts avant de continuer). État en mémoire uniquement, aucun schéma de persistance modifié.\n\nDécide et exécute (périmètre LOCAL uniquement — aucun push) : faut-il créer une branche feature/* (et depuis quelle base — develop ?), faut-il d'abord (re)créer/checkout develop depuis main, ou rester en place ? Donne-moi le nom de branche retenu et confirme l'état git après ta manœuvre."}
+{"id":"4309abd6-8ded-4641-9a46-af523f0f1af6","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781612520039,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"Décision (agent Git) — branche retenue : **`feature/agent-session-limits`**, créée **depuis `develop`**.\n\n**Raisonnement :**\n- Nouvelle feature indépendante (LS1→LS8) → conformément au modèle `main ← develop ← feature/*`, elle se développe sur sa propre branche `feature/*`.\n- Pas besoin de (re)créer `develop` : il existe déjà et est à jour (post-release 0.1.0, `git diff main develop` vide → contenu identique). C'est donc la bonne base de départ.\n- Nom dérivé du sujet, kebab-case : `feature/agent-session-limits`.\n\n**État git après manœuvre (LOCAL, aucun push) :**\n- Branche courante : `feature/agent-session-limits` @ `401c18a` (= base `develop`).\n- `develop` @ `401c18a` (inchangé) ← `main` @ `9a8a89f` (tag `v0.1.0`, inchangé).\n- `feature/agent-skills` @ `ef101db` (autre feature, intacte).\n\n**Note :** le working tree porte déjà des changements non commités hérités de l'état courant — notamment `ARCHITECTURE.md` (cadrage Architect) et un nouveau `.ideai/memory/session-limit-handling-design.md`, plus du runtime `.ideai/` (conversations/MEMORY.md). Ils n'ont pas été commités : DevBackend/QA les intégreront dans les commits de la feature au fil des lots. Le cadrage Architect (ARCHITECTURE.md + memory design) pourra faire le **premier commit** de la branche avant LS1 si tu le souhaites — dis-moi si tu veux que je le commite maintenant.\n\nDev peut démarrer LS1 (domaine) sur `feature/agent-session-limits`. Après chaque lot vert, reviens vers moi pour décider d'un éventuel commit/merge. Aucune intégration vers `develop` tant que les tests des lots concernés ne sont pas verts (règle d'or)."}
+{"id":"8edd3bc3-3024-46b6-929b-2aac1c1f7fdc","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781612678980,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Feu vert pour le premier commit de la branche feature/agent-session-limits : commite le cadrage AVANT que le dev (LS1) ne démarre, pour isoler proprement le cadrage du code.\n\nContenu à committer (cadrage uniquement) : ARCHITECTURE.md (nouvelle §21) + .ideai/memory/session-limit-handling-design.md + la mise à jour de .ideai/memory/MEMORY.md (pointeur).\n\nN'inclus PAS le runtime .ideai/ non pertinent (conversations, layouts, agents.json…) s'il pollue le diff — limite le commit aux fichiers du cadrage. Message de commit conforme au style du dépôt (français, conventionnel). Périmètre LOCAL uniquement — aucun push. Confirme le hash du commit et l'état git après."}
+{"id":"bdcd087a-9481-4a06-a8a9-20881cb93077","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781612714298,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"Cadrage committé sur `feature/agent-session-limits` — premier commit de la branche, isolé du code.\n\n**Commit : `fa5b826`**\n`docs(session-limits): cadrage Architect — gestion des limites de session des agents`\n\n**Contenu (cadrage uniquement, 3 fichiers / +212 lignes) :**\n- `ARCHITECTURE.md` (+185, nouvelle §21)\n- `.ideai/memory/session-limit-handling-design.md` (nouveau, design validé)\n- `.ideai/memory/MEMORY.md` (+1, pointeur)\n\nLe runtime `.ideai/` non pertinent (conversations, layouts, agents.json…) a été **exclu** du diff comme demandé.\n\n**État git après commit (LOCAL, aucun push) :**\n- `feature/agent-session-limits` @ `fa5b826` ← `develop` @ `401c18a` ← `main` @ `9a8a89f` (tag `v0.1.0`).\n- Working tree : reste uniquement du runtime `.ideai/conversations/…` non commité (bruit, ignoré pour le cadrage).\n\nLa branche est prête : le dev peut démarrer **LS1 (domaine)**. Je reviendrai dans la boucle pour committer chaque lot vert."}
+{"id":"45759b66-4412-4756-aa61-9f2388dae1b4","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781613219445,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"LS1 (couche domaine) de la feature « limites de session » est VERT : DevBackend a livré le code pur, QA a écrit 24 tests, `cargo test -p domain` = 165 passed / 0 failed, zéro régression.\n\nCommite LS1 sur feature/agent-session-limits (commit suivant après le cadrage fa5b826). Périmètre LOCAL uniquement, aucun push.\n\nFichiers de prod (domaine) modifiés/créés par DevBackend :\n- crates/domain/src/ports.rs (variante ReplyEvent::RateLimited)\n- crates/domain/src/readiness.rs (variante ReadinessSignal::RateLimited + classify)\n- crates/domain/src/session_limit.rs (NOUVEAU : SessionLimit, ResumePlan, RateLimitSource, plan_resume)\n- crates/domain/src/profile.rs (RateLimitPattern + champ + builder)\n- crates/domain/src/events.rs (5 variantes DomainEvent)\n- crates/domain/src/lib.rs (mod + re-exports)\nPlus les tests QA dans ces mêmes fichiers (#[cfg(test)]).\n\nN'inclus PAS le runtime .ideai/ non pertinent. Message conventionnel en français.\n\nIMPORTANT — décision de merge : NE merge PAS vers develop maintenant. Le workspace complet (`cargo build --workspace`) NE COMPILE PAS tant que LS2 n'a pas ajouté l'arm `ReplyEvent::RateLimited` côté infra (match exhaustifs). On ne merge feature/* → develop que sur une tranche qui compile de bout en bout (cible : LS1+LS2+LS4 = niveau 1 Claude complet). Confirme juste le hash du commit LS1 et l'état git."}
+{"id":"6f923008-d23b-4c0f-8118-0b0bd82baeb1","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781613250449,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"LS1 (couche domaine) committé sur `feature/agent-session-limits`, après le cadrage `fa5b826`.\n\n**Commit : `0bf1eb3`**\n`feat(session-limits): LS1 — couche domaine (détection + plan de reprise)`\n\n**Contenu (6 fichiers domaine, prod + tests inline / +647 lignes) :**\n- `crates/domain/src/session_limit.rs` (nouveau)\n- `crates/domain/src/ports.rs` (ReplyEvent::RateLimited)\n- `crates/domain/src/readiness.rs` (ReadinessSignal::RateLimited + classify)\n- `crates/domain/src/profile.rs` (RateLimitPattern + champ + builder)\n- `crates/domain/src/events.rs` (5 variantes DomainEvent)\n- `crates/domain/src/lib.rs` (mod + re-exports)\n\nRuntime `.ideai/` non pertinent **exclu**.\nQA : `cargo test -p domain` = 165 passed / 0 failed, zéro régression.\n\n**Décision de merge : PAS de merge vers `develop`** — conforme à ta consigne. Le workspace ne compile pas tant que LS2 n'a pas ajouté l'arm `ReplyEvent::RateLimited` côté infra (match exhaustifs). On n'intègre `feature/* → develop` que sur une tranche qui compile de bout en bout (cible : LS1+LS2+LS4 = niveau 1 Claude complet). Je reste sur la branche feature.\n\n**État git (LOCAL, aucun push) :**\n```\nfeature/agent-session-limits @ 0bf1eb3  (HEAD)\n  └ fa5b826  docs cadrage\n  └ 401c18a  (develop) ← main @ 9a8a89f (tag v0.1.0)\n```\nWorking tree : seul du runtime `.ideai/conversations/…` non commité (ignoré). Dev peut enchaîner sur LS2."}
+{"id":"8cd389e5-7f84-4737-af3a-207438d2fc62","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781613878608,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"LS2 (adapter Claude niveau 1, infra) est VERT : `cargo test -p infrastructure` = 188 passed / 0 failed, zéro régression. Commite LS2 sur feature/agent-session-limits (après LS1 0bf1eb3). LOCAL uniquement, aucun push.\n\nFichier de prod modifié : crates/infrastructure/src/session/claude.rs (parse_event émet ReplyEvent::RateLimited ; nouvelle fonction pure parse_reset_ms + helpers ; parseur ISO maison ; doccomments T4).\nTests QA : dans crates/infrastructure/src/session/mod.rs (#[cfg(test)]) — 26 nouveaux tests + 2 tests existants mis à jour vers le nouveau contrat ; et crates/infrastructure/src/session/conformance.rs (#[cfg(test)] : RateLimited ajouté aux événements non terminaux autorisés).\n\nExclu le runtime .ideai/. Message conventionnel français.\n\nDécision merge : TOUJOURS PAS de merge vers develop (le workspace ne compile pas encore — 2 erreurs résiduelles attendues dans app-tauri, relèvent de LS7/LS8 ; et la réconciliation T4 reste à faire en LS4). On vise la tranche LS1+LS2+LS3+LS4 = niveau 1 Claude de bout en bout qui compile, pour le premier merge. Confirme le hash LS2 et l'état git."}
+{"id":"38531764-1e1c-414c-93a9-266cf6847444","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781613904809,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"LS2 (adapter Claude niveau 1, infra) committé sur `feature/agent-session-limits`, après LS1 `0bf1eb3`.\n\n**Commit : `a1755e5`**\n`feat(session-limits): LS2 — adapter Claude niveau 1 (infra)`\n\n**Contenu (3 fichiers infra, prod + tests inline / +545 lignes) :**\n- `crates/infrastructure/src/session/claude.rs` (prod : parse_event → ReplyEvent::RateLimited, parse_reset_ms + helpers, parseur ISO maison, doccomments T4)\n- `crates/infrastructure/src/session/mod.rs` (26 nouveaux tests QA + 2 alignés)\n- `crates/infrastructure/src/session/conformance.rs` (RateLimited en non-terminal autorisé)\n\nRuntime `.ideai/` **exclu**.\nQA : `cargo test -p infrastructure` = 188 passed / 0 failed, zéro régression.\n\n**Décision de merge : TOUJOURS PAS de merge vers `develop`** — conforme. Le workspace ne compile pas encore (2 erreurs résiduelles attendues dans app-tauri → LS7/LS8 ; réconciliation T4 → LS4). Premier merge visé sur la tranche **LS1+LS2+LS3+LS4 = niveau 1 Claude de bout en bout qui compile**.\n\n**État git (LOCAL, aucun push) :**\n```\nfeature/agent-session-limits @ a1755e5  (HEAD)\n  └ 0bf1eb3  LS1 domaine\n  └ fa5b826  cadrage\n  └ 401c18a  (develop) ← main @ 9a8a89f (tag v0.1.0)\n```\nWorking tree : seul du runtime `.ideai/` non commité (ignoré). Dev peut enchaîner sur LS3."}
+{"id":"49eb0b0d-ee02-4497-b676-127436f10222","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781615248432,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"LS3 (port Scheduler + adapter TokioScheduler) est VERT : `cargo test -p infrastructure` = 195 passed / 0 failed (7 nouveaux tests scheduler, relancés 3× sans flaky), LS1/LS2 toujours verts. Builds domaine + infra OK 0 warning. Le workspace complet ne compile toujours pas (2 erreurs résiduelles inchangées dans app-tauri : chat.rs:185 → LS8, events.rs:261 → LS7 ; la réconciliation T4 reste en LS4).\n\nC'est TOI qui décides quoi et quand committer/merger. Je te livre l'état, tu tranches.\n\nFichiers de prod LS3 :\n- crates/domain/src/ids.rs (ScheduleId via typed_id!)\n- crates/domain/src/ports.rs (trait Scheduler + enum ScheduledTask)\n- crates/domain/src/lib.rs (re-exports)\n- crates/infrastructure/src/scheduler/mod.rs (NOUVEAU : TokioScheduler)\n- crates/infrastructure/src/lib.rs (pub mod scheduler + re-export)\nTests QA : dans crates/infrastructure/src/scheduler/mod.rs (#[cfg(test)]).\nRuntime .ideai/ à exclure du diff.\n\nDécide : faut-il committer LS3 maintenant (et avec quel message) ? Et concernant le merge vers develop — rappel du contexte : le premier merge envisagé portait sur la tranche LS1+LS2+LS3+LS4 (niveau 1 Claude de bout en bout qui compile), or le workspace ne compile pas encore (LS4 + app-tauri manquants). Dis-moi ta décision (commit LS3 sur la feature ? attendre la tranche compilable pour merger ? autre ?) et exécute-la. Confirme hash + état git."}
+{"id":"acc7dd08-37bf-422e-8962-00778f60de6c","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781615283463,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"Décision (agent Git) : **commit LS3 sur la feature, PAS de merge vers `develop`.**\n\n**Pourquoi :** chaque lot vert mérite son commit atomique sur la branche feature (traçabilité, bissection facile), mais le merge `feature/* → develop` exige une tranche qui **compile de bout en bout** — règle d'or. Or le workspace ne compile toujours pas (réconciliation T4 en LS4 + 2 erreurs résiduelles app-tauri : `chat.rs:185`→LS8, `events.rs:261`→LS7). Donc on continue d'accumuler sur la feature ; premier merge maintenu sur la tranche compilable (LS1+LS2+LS3+LS4 niveau 1 Claude, voire jusqu'à LS7/LS8 si la compilation workspace n'est verte qu'à ce moment-là).\n\n**Commit : `253310b`**\n`feat(session-limits): LS3 — port Scheduler + adapter TokioScheduler`\n\n**Contenu (5 fichiers prod + tests inline / +389 lignes) :**\n- domaine : `ports.rs` (trait Scheduler + enum ScheduledTask), `ids.rs` (ScheduleId), `lib.rs` (re-exports)\n- infra : `scheduler/mod.rs` (nouveau, TokioScheduler), `lib.rs` (pub mod + re-export)\n\nRuntime `.ideai/` **exclu**.\nQA : `cargo test -p infrastructure` = 195 passed / 0 failed (7 tests scheduler, 3× sans flaky) ; LS1/LS2 verts ; builds domaine+infra 0 warning.\n\n**État git (LOCAL, aucun push) :**\n```\nfeature/agent-session-limits @ 253310b  (HEAD)\n  └ a1755e5  LS2 adapter Claude\n  └ 0bf1eb3  LS1 domaine\n  └ fa5b826  cadrage\n  └ 401c18a  (develop) ← main @ 9a8a89f (tag v0.1.0)\n```\nDev peut enchaîner sur LS4 (service application + réconciliation T4). Je tranche le merge dès que le workspace compile."}
+{"id":"0465aea2-3a1c-486a-9afb-4ad04f91d6d0","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781628910047,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"LS4 (couche application : SessionLimitService + réconciliation T4) est VERT : `cargo test -p application` = tous binaires verts / 0 failed (16 nouveaux tests), zéro régression confirmée (drain_with_readiness_lot1 7/7, send_blocking_d1 9/9, reste du crate vert). Builds domaine+infra+application 0 warning. Le workspace complet ne compile TOUJOURS pas (inchangé : app-tauri chat.rs:185 → LS8, events.rs:261 → LS7).\n\nC'est toi qui décides quoi/quand committer/merger. État livré :\n\nFichiers de prod LS4 :\n- crates/application/src/agent/session_limit.rs (NOUVEAU : SessionLimitService + port AgentResumer + const RESUME_PROMPT)\n- crates/application/src/agent/structured.rs (réconciliation T4 : enum TurnOutcome + drain_with_readiness_outcome ; signatures historiques préservées)\n- crates/application/src/agent/mod.rs (mod + re-exports)\n- crates/application/src/lib.rs (re-exports)\nTests QA : crates/application/tests/session_limit_service.rs (9) + crates/application/tests/session_limit_t4.rs (7) (NOUVEAUX).\nRuntime .ideai/ à exclure.\n\nDécide et exécute (commit LS4 sur la feature ? message ? merge ou pas ?). Pour mémoire : le workspace ne compile de bout en bout qu'après LS7 (events app-tauri) + LS8 (chat.rs) ; le premier merge vers develop reste donc subordonné à ta règle d'or « tranche qui compile ». Confirme hash + état git."}
+{"id":"f88d6a5a-0e2b-4cd8-bb09-aa4534bfb453","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781628940614,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"Décision (agent Git) : **commit LS4 sur la feature, PAS de merge vers `develop`.**\n\n**Commit : `9000b4d`**\n`feat(session-limits): LS4 — service application + réconciliation T4`\n\n**Contenu (6 fichiers, 4 prod + 2 tests / +987 lignes) :**\n- `crates/application/src/agent/session_limit.rs` (nouveau : SessionLimitService + port AgentResumer + RESUME_PROMPT)\n- `crates/application/src/agent/structured.rs` (T4 : enum TurnOutcome + drain_with_readiness_outcome, signatures historiques préservées)\n- `crates/application/src/agent/mod.rs` + `crates/application/src/lib.rs` (modules/re-exports)\n- `crates/application/tests/session_limit_service.rs` (9) + `crates/application/tests/session_limit_t4.rs` (7) — nouveaux\n\nRuntime `.ideai/` **exclu**.\nQA : `cargo test -p application` tous binaires verts / 0 failed (16 nouveaux) ; zéro régression (drain_with_readiness_lot1 7/7, send_blocking_d1 9/9) ; builds domaine+infra+application 0 warning.\n\n**Décision de merge : toujours NON.** La tranche LS1→LS4 est verte par crate, mais `cargo build --workspace` échoue encore (app-tauri : `chat.rs:185`→LS8, `events.rs:261`→LS7). Ma règle d'or impose une tranche qui **compile de bout en bout** avant tout `feature/* → develop`. Comme tu me l'as confirmé, le workspace ne sera vert qu'après LS7+LS8 → **le premier merge se fera donc sur LS1→LS8** (et non LS1→LS4 comme envisagé initialement). On accumule jusque-là sur la branche feature.\n\n**État git (LOCAL, aucun push) :**\n```\nfeature/agent-session-limits @ 9000b4d  (HEAD)\n  └ 253310b LS3 · a1755e5 LS2 · 0bf1eb3 LS1 · fa5b826 cadrage\n  └ 401c18a (develop) ← main @ 9a8a89f (tag v0.1.0)\n```\nDev peut enchaîner sur LS5 (parser regex). Je tranche le merge dès `cargo build --workspace` vert."}
+{"id":"dedd197e-7de5-4e64-8217-54be77e1e653","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781629554554,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"LS5 (parser regex niveau 2, infra) est VERT : `cargo test -p infrastructure` = 221 passed / 0 failed (26 nouveaux), 0 warning, LS2/LS3 toujours verts (refactor timeparse non régressif). C'est toi qui décides commit/merge.\n\nFichiers de prod LS5 :\n- crates/infrastructure/Cargo.toml (dépendance regex = \"1\", résout 1.12.3 déjà dans Cargo.lock)\n- crates/infrastructure/src/ratelimit/mod.rs (NOUVEAU : RateLimitParser + applies)\n- crates/infrastructure/src/timeparse.rs (NOUVEAU : parsing d'heure pur partagé, factorisé depuis LS2)\n- crates/infrastructure/src/session/claude.rs (délègue à timeparse — refactor)\n- crates/infrastructure/src/lib.rs (pub mod ratelimit + timeparse, re-export)\nModifs de TEST QA : crates/infrastructure/src/ratelimit/mod.rs (#[cfg(test)] 15 tests), crates/infrastructure/src/timeparse.rs (#[cfg(test)] 11 tests), crates/infrastructure/src/scheduler/mod.rs (2 warnings irrefutable if let corrigés dans le code de test).\nNOTE : Cargo.lock peut être inchangé (regex déjà verrouillée) — inclus-le seulement s'il bouge.\nRuntime .ideai/ à exclure.\n\nDécide et exécute (commit LS5 ? message ? merge ?). Pour mémoire le workspace ne compile de bout en bout qu'après LS7+LS8. Confirme hash + état git."}
+{"id":"050c6d11-d9bb-4e0f-8bc8-cebae970cbe3","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781632920754,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Feature session-limits, suite. Project root: /home/anthony/Documents/Projects/IdeA. Deux lots sont terminés et VERTS (workspace compile, `cargo test --workspace` tout vert, clippy propre sur le nouveau code) mais NON committés :\n\n- LS5 — détecteur niveau 2 déclaratif + parsing temps partagé. Fichiers : nouveau `crates/infrastructure/src/ratelimit/mod.rs` (RateLimitParser, regex confiné infra), nouveau `crates/infrastructure/src/timeparse.rs` (parsing d'heures pur, partagé niveau 1/2), modifs `crates/infrastructure/src/session/claude.rs` (refactor vers timeparse, ~-121 lignes), `crates/infrastructure/src/scheduler/mod.rs`, `crates/infrastructure/src/lib.rs` (exports), `crates/infrastructure/Cargo.toml` (dép `regex`), `Cargo.lock`.\n- LS6 — câblage des 5 nouvelles variantes DomainEvent (AgentRateLimited/ResumeScheduled/ResumeCancelled/Resumed/RateLimitSuspected) + ReplyEvent::RateLimited vers le front. Fichiers : `crates/app-tauri/src/events.rs` (DTO miroir + bras From + test relais), `crates/app-tauri/src/chat.rs` (chunk_from_event).\n\nNote : l'arbre contient aussi des fichiers runtime .ideai/ modifiés (conversations/*/handoff.md, log.jsonl, layouts.json, memory/) et un nouveau memory `git-owns-commit-merge-decisions.md` — à toi de juger ce qui entre ou non dans le(s) commit(s) applicatif(s) (rappel : les LS précédents committaient uniquement le code applicatif, pas le bruit runtime).\n\nLa branche courante est détachée (HEAD), pas sur develop. À toi de décider : topologie de branche, découpage en un ou deux commits (LS5 puis LS6, ou groupés), messages dans le style des commits feat(session-limits) existants, et si un merge feature/* → develop doit suivre. Périmètre LOCAL uniquement (aucun push). Exécute ta décision et rends via idea_reply le détail (branche, sha, messages, état final de `git status`)."}
+{"id":"8f8eec4e-104d-424d-b061-39fc93ad1bde","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781632975720,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"Fait. Décisions et exécution :\n\n**Branche** — Contrairement à ce qui était annoncé, HEAD n'était pas détachée : on était bien sur `feature/agent-session-limits` (la branche de la feature). Aucune création/bascule nécessaire, le dev se poursuit dessus. Rien à corriger.\n\n**Découpage — 2 commits atomiques** (LS5 puis LS6, séparés car deux intentions distinctes : couche infra de détection vs câblage événementiel vers le front) :\n\n1. `98bfcf4` — feat(session-limits): LS5 — détecteur niveau 2 déclaratif + parsing temps partagé\n   Fichiers : `crates/infrastructure/src/ratelimit/mod.rs` (nouv.), `crates/infrastructure/src/timeparse.rs` (nouv.), `crates/infrastructure/src/session/claude.rs`, `crates/infrastructure/src/scheduler/mod.rs`, `crates/infrastructure/src/lib.rs`, `crates/infrastructure/Cargo.toml`, `Cargo.lock`.\n\n2. `ea94e75` — feat(session-limits): LS6 — câblage des événements de limite vers le front\n   Fichiers : `crates/app-tauri/src/events.rs`, `crates/app-tauri/src/chat.rs`.\n\nMessages en français, style Conventional Commits cohérent avec LS1→LS4, corps expliquant le pourquoi, co-author inclus.\n\n**Bruit runtime exclu** — Non committé, comme pour les LS précédents : `.ideai/conversations/*` (handoff.md, log.jsonl), `.ideai/layouts.json`, `.ideai/memory/` (dont MEMORY.md et le nouveau `git-owns-commit-merge-decisions.md`), et la nouvelle conversation `6bc594e8-…`. Ce sont des artefacts d'exécution, pas du code applicatif.\n\n**Merge feature/* → develop : NON.** La feature session-limits est livrée par incréments (série LS en cours) ; LS5/LS6 sont verts mais internes (détecteur niveau 2 + relais d'événements) sans surface produit complète. On reste sur `feature/agent-session-limits`. Le merge vers `develop` se fera quand la feature sera terminée et toujours verte.\n\n**Périmètre** — 100% local, aucun push.\n\n**État final `git status`** : working tree propre côté applicatif ; ne subsistent que les fichiers runtime `.ideai/` modifiés/non suivis (volontairement hors commit). Derniers commits :\nea94e75 LS6 / 98bfcf4 LS5 / 9000b4d LS4."}
+{"id":"9c73943b-e258-4c2b-a124-f2eafffe3c5a","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781675740301,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Slice LS7 (backend / câblage app-tauri) de la feature session-limits terminée et verte. On est sur la branche feature/agent-session-limits (HEAD détaché ? `git status` montre HEAD), dernier commit ea94e75 (LS6).\n\nContenu à committer (tout est vert, aucun warning) :\n- crates/application/src/agent/lifecycle.rs : `LaunchAgentOutput.profile` exposé (None sur réattache/idempotent, Some sur lancement effectif).\n- crates/application/src/terminal/registry.rs : `StructuredSessions::meta_for_session()` (lookup agent/node par SessionId pour le tap niveau 1).\n- crates/app-tauri/src/state.rs : `ResumeContext`/`ResumeContexts`, `AppAgentResumer` (impl port `AgentResumer` au-dessus de LaunchAgent), instanciation+câblage du `SessionLimitService` (TokioScheduler + drain des réveils) dans `AppState::build`.\n- crates/app-tauri/src/commands.rs : taps niveau 1 (agent_send) et niveau 2 (launch_agent, parser regex confiné), alimentation de `resume_contexts`, nouvelle commande `cancel_resume`.\n- crates/app-tauri/src/lib.rs : enregistrement de `cancel_resume` dans le handler.\n- crates/app-tauri/Cargo.toml : dépendance `async-trait`.\n- crates/app-tauri/tests/session_limit_wiring.rs : 2 tests d'intégration (composition) — verts.\n- crates/app-tauri/tests/dto_agents.rs + dto_chat.rs : ajustement `profile: None` dans les fixtures.\n- crates/application/tests/structured_registry_d1.rs : test de `meta_for_session`.\n\nHors périmètre code (à NE PAS committer dans ce commit applicatif) : .ideai/conversations/**, .ideai/layouts.json, .ideai/memory/** — ce sont des artefacts runtime/mémoire.\n\nQuestions : 1) Faut-il committer cette slice LS7-backend maintenant, et sous quel message ? 2) Reste-t-on sur feature/agent-session-limits ? 3) Décides-tu d'un merge vers develop, ou on attend LS7-front (React/TS, badge + compte à rebours + filet humain) qui complète la surface produit ? Tranche et exécute le commit applicatif si tu juges que oui."}
+{"id":"42185422-903a-4c25-8139-b63748f6dd73","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781675787986,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"Décision Git — LS7 backend committée, on reste en feature, pas de merge maintenant.\n\nÉtat initial : on était bien **sur la branche** `feature/agent-session-limits` (pas de HEAD détaché — le « HEAD » de ton `git status` était juste l'en-tête francisé), HEAD = ea94e75 (LS6).\n\n1) ✅ Commit fait. Hash **9df5923** :\n`feat(session-limits): LS7 — câblage backend app-tauri (taps niveaux 1&2 + reprise annulable)`\n- 10 fichiers, +406/−3, dont la création de `tests/session_limit_wiring.rs`.\n- Périmètre strictement applicatif : lifecycle.rs, registry.rs, state.rs, commands.rs, lib.rs, Cargo.toml + les 4 fichiers de tests.\n- **Exclus comme demandé** (restés non-stagés, ce sont des artefacts runtime/mémoire) : `.ideai/conversations/**`, `.ideai/layouts.json`, `.ideai/memory/**` (dont le nouveau `git-owns-commit-merge-decisions.md` et le `6bc594e8…/` non suivi). Commit atomique = code seulement.\n\n2) ✅ On **reste sur `feature/agent-session-limits`**. La feature n'est pas terminée côté produit (il manque LS7-front), donc on continue dessus.\n\n3) ❌ **Pas de merge vers `develop` maintenant.** Raison : la slice est verte mais la surface produit session-limits est **incomplète sans LS7-front** (badge + compte à rebours + filet humain). Merger le backend seul livrerait dans `develop` une mécanique de reprise annulable sans son UI de contrôle/annulation visible — état intermédiaire que je ne veux pas figer dans l'intégration. **On attend LS7-front.** Une fois le front implémenté et la suite complète verte, reviens vers moi : je rebase si besoin sur `develop`, puis merge `--no-ff` la feature entière d'un coup (backend + front cohérents).\n\nProchaine étape côté toi : enchaîner LS7-front (React/TS) sur cette même branche. Quand c'est vert, ping-moi pour le merge d'intégration."}
+{"id":"4d281c8d-2a92-45b8-ac22-9a8fac5aafde","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781676394147,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Slice LS7-front (React/TS, UI limites de session) terminée et VERTE sur `feature/agent-session-limits`.\n\nÉtat tests : `npx vitest run src/features/agents/` → 4 fichiers, 63 tests passés (39 existants + 24 nouveaux), 0 régression. Typecheck `tsc --noEmit` propre.\n\nFichiers à committer (frontend/ uniquement) :\n- src/domain/index.ts — 5 variantes ajoutées au union DomainEvent (agentRateLimited/ResumeScheduled/ResumeCancelled/Resumed/RateLimitSuspected).\n- src/ports/index.ts — `cancelResume(agentId)` ajouté à InputGateway.\n- src/adapters/input.ts — TauriInputGateway.cancelResume → invoke(\"cancel_resume\", { agentId }).\n- src/adapters/mock/index.ts — MockInputGateway.cancelResume (cancelledResumes/cancelResumeResult).\n- src/features/agents/useAgents.ts — état limitByAgent + action cancelResume.\n- src/features/agents/AgentLimitBadge.tsx — NOUVEAU (badge + compte à rebours + bouton Annuler + helpers purs).\n- src/features/agents/AgentsPanel.tsx — câblage du badge.\n- src/features/agents/useAgentsLimits.test.tsx — NOUVEAU (13 tests, QA).\n- src/features/agents/AgentLimitBadge.test.tsx — NOUVEAU (11 tests, QA).\n\nHors périmètre (NE PAS committer) : .ideai/** (artefacts runtime/mémoire). Aucun fichier backend touché.\n\nNOTE : il existe un test PRÉEXISTANT rouge SANS rapport avec cette slice — `src/adapters/mock/mock.test.ts:16` asserte « thirteen gateways » alors qu'il y en a 14 (gateway `permission` déjà présente dans HEAD committé eca2ba9). Compteur périmé, pas causé par LS7-front. À toi de voir si tu veux que je fasse corriger ce compteur (tâche séparée DevFrontend) avant/après — dis-moi.\n\nQuestions : 1) Committe la slice LS7-front maintenant ? Sous quel message ? 2) Le merge --no-ff de la feature complète vers develop : on attend que je tranche le dernier point de scope (filet humain niveau 3 — voir consultation Architect en cours : peut nécessiter une slice backend+front supplémentaire `set_resume_at`), donc NE merge pas encore vers develop — confirme que tu te limites au commit de cette slice et qu'on garde le merge pour quand je te recontacte « feature complète ». Tranche et exécute le commit."}
+{"id":"21dcba39-7c5a-4191-8ddb-f13ab7eed54e","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781676433750,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"Décision Git — LS7-front committée, pas de merge develop (j'attends ton « feature complète »).\n\n1) ✅ Commit fait. Hash **4fad042** :\n`feat(session-limits): LS7-front — UI limites de session (badge + compte à rebours + filet humain)`\n- 9 fichiers, +702/−1, dont 3 créations (AgentLimitBadge.tsx + ses 2 fichiers de tests).\n- Périmètre strictement frontend : domain/index.ts, ports/index.ts, adapters/input.ts, adapters/mock/index.ts, useAgents.ts, AgentLimitBadge.tsx, AgentsPanel.tsx + les 2 tests.\n- **Exclus comme demandé** (non-stagés) : `.ideai/**` (conversations, layouts, memory) et `node_modules/` (non suivi — au passage, il traîne en untracked ; à gitignorer dans une tâche d'hygiène séparée si ce n'est pas déjà couvert, mais hors périmètre ici). Aucun fichier backend touché. Commit atomique = frontend seulement.\n\n2) ✅ Confirmé : **je me limite à ce commit, pas de merge vers `develop`.** Je garde le `--no-ff` d'intégration de la feature complète pour quand tu me recontactes « feature complète », une fois tranché le scope du filet humain niveau 3 (slice `set_resume_at` éventuelle, cf. consultation Architect).\n\nConcernant le **test préexistant rouge** `mock.test.ts:16` (« thirteen gateways » → 14 réelles, gateway `permission` déjà dans HEAD eca2ba9) : compteur périmé sans rapport avec LS7. Mon avis Git : à corriger **avant le merge d'intégration**, en **commit séparé** (`fix(test): …` ou `chore(test): …`), pour ne pas merger `develop` avec une suite rouge. Lance une tâche DevFrontend dédiée quand tu veux ; tu peux l'enchaîner maintenant ou la grouper avec l'éventuelle slice `set_resume_at` — dans tous les cas elle aura son propre commit, et je ne mergerai pas tant que toute la suite n'est pas verte.\n\nÉtat branche : `feature/agent-session-limits` → … ea94e75 (LS6) · 9df5923 (LS7 back) · **4fad042 (LS7 front, HEAD)**."}
+{"id":"8a9caf1e-94cf-4d45-905a-caab1363aa99","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781678668760,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Feature session-limits COMPLÈTE (3 niveaux) et verte. Reste à committer 2 slices, puis on peut envisager le merge d'intégration `feature/agent-session-limits → develop` que tu gardais en attente.\n\nÉtat branche actuel : … 9df5923 (LS7 back) · 4fad042 (LS7 front, HEAD). Travail NON committé depuis, à committer maintenant en 2 commits séparés :\n\n═══ COMMIT A — LS8-backend (filet humain niveau 3, backend) ═══\nImplémenté par DevBackend, testé par QA (application: 15 tests session_limit_service / app-tauri: 4 wiring, + régressions vertes, 0 failed).\nFichiers :\n- crates/application/src/agent/session_limit.rs — refactor privé `arm_scheduled` (param `resets_at_ms` brut ajouté) partagé par `on_rate_limited` + nouvelle `pub fn confirm_human_resume(agent_id, node_id, conversation_id, resets_at_ms: i64)` (source Human, réutilise la branche Scheduled, annulable).\n- crates/app-tauri/src/commands.rs — nouvelle commande `set_resume_at(agent_id, resets_at_ms) -> Result<(), ErrorDto>` (résout node_id via node_for_agent + conversation_id best-effort, NOT_FOUND si pas de cellule vivante).\n- crates/app-tauri/src/lib.rs — `set_resume_at` enregistrée après `cancel_resume`.\n- crates/application/tests/session_limit_service.rs — +6 tests (QA).\n- crates/app-tauri/tests/session_limit_wiring.rs — +2 tests (QA).\nAucun événement nouveau (réutilise AgentRateLimited + AgentResumeScheduled).\n\n═══ COMMIT B — LS8-front + fix test (DevFrontend a demandé 2 commits ; à toi de voir si tu sépares ou regroupes) ═══\nLS8-front (typecheck propre, 109 tests verts) :\n- frontend/src/ports/index.ts — `setResumeAt(agentId, resetsAtMs)` sur InputGateway.\n- frontend/src/adapters/input.ts — `setResumeAt` → invoke(\"set_resume_at\", { agentId, resetsAtMs }).\n- frontend/src/adapters/mock/index.ts — MockInputGateway.setResumeAt (resumeArmings[]).\n- frontend/src/features/agents/useAgents.ts — action setResumeAt (sans mutation optimiste).\n- frontend/src/features/agents/AgentLimitBadge.tsx — formulaire de saisie d'heure sur l'état suspected sans heure + helper pur `timeInputToEpochMs` ; TODO LS7 retiré.\n- frontend/src/features/agents/AgentsPanel.tsx — câblage onSetResumeAt.\n- frontend/src/features/agents/AgentLimitBadge.test.tsx — tests mis à jour au nouveau contrat + couverture LS8.\nFix test hygiène (DevFrontend recommande commit SÉPARÉ) :\n- frontend/src/adapters/mock/mock.test.ts — compteur gateways 13→14 (« thirteen »→« fourteen » + `permission` dans l'array). Vérifié : 14 gateways réelles.\n\nHors périmètre (NE PAS committer) : .ideai/** (runtime/mémoire), node_modules/ (untracked — DevFrontend signalait qu'il traîne, à gitignorer dans une tâche d'hygiène séparée, hors périmètre ici).\n\nQUESTIONS : 1) Committe COMMIT A puis les commits front (LS8-front + fix-test, séparés ou groupés selon ton jugement). Donne-moi les hashes + messages. 2) La suite complète est maintenant verte (Rust: domain/application/app-tauri ; front: agents + adapters/mock 109 tests) et la surface produit session-limits est complète sur les 3 niveaux. Décides-tu MAINTENANT le merge `--no-ff` vers develop (rebase si besoin) ? Si oui, exécute-le et donne-moi le résultat. Si tu veux un dernier garde-fou (ex. run de la suite complète des deux côtés avant merge), dis-le et je le fais lancer."}
+{"id":"6df9f7b7-fcc4-4b87-94db-33dce2d76f13","conversation":"6bc594e8-a37c-0dbd-1de6-6e3b73002cb4","atMs":1781678766649,"source":{"kind":"agent","agentId":"cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5"},"role":"response","text":"✅ 3 commits + merge d'intégration faits. La feature session-limits est intégrée dans `develop`.\n\n═══ 1) Les 3 commits (sur feature/agent-session-limits) ═══\nJ'ai séparé le fix-test de la feature (hygiène isolée, comme recommandé par DevFrontend) → 3 commits :\n\n- **c480d28** `feat(session-limits): LS8-backend — filet humain niveau 3 (set_resume_at)`\n  (session_limit.rs + commands.rs + lib.rs + tests service/wiring ; 5 fichiers, +394/−18)\n- **5d9dd32** `feat(session-limits): LS8-front — filet humain niveau 3 (saisie d'heure de reprise)`\n  (ports/input/mock + useAgents + AgentLimitBadge(.tsx/.test) + AgentsPanel ; 7 fichiers, +222/−26)\n- **3f3504e** `fix(test): corrige le compteur de gateways du mock (13 → 14)`\n  (mock.test.ts isolé ; 1 fichier, +2/−1)\n\nArtefacts `.ideai/**` et `node_modules/` exclus comme demandé.\n\n═══ 2) Merge `--no-ff` → develop : OUI, exécuté ═══\nDécision : la surface produit est complète sur les 3 niveaux et tout est vert des deux côtés → je merge. Pas de rebase nécessaire : `feature` était **12 ahead / 0 behind** `develop` (aucune divergence, base linéaire).\n\n- Merge commit : **d7041c5** `merge(session-limits): intégration de la feature limites de session (3 niveaux)` — stratégie ort, **0 conflit**, 47 fichiers / +5157/−45 (cumul LS2→LS8).\n- `develop` est maintenant à **d7041c5**, contenant toute la chaîne LS2 (a1755e5) → LS8 (3f3504e).\n- La branche `feature/agent-session-limits` est **conservée** (pas supprimée) : je la garde tant que tu n'as pas confirmé que l'intégration est définitivement validée. Dis-moi si tu veux que je la supprime maintenant.\n\nNote d'exécution : les artefacts runtime `.ideai/**` non committés bloquaient le switch de branche → je les ai **stashés le temps du merge puis restaurés** (stash poppé, working tree intact, rien perdu). Aucun de ces artefacts n'est entré dans les commits applicatifs ni dans le merge.\n\n⚠️ Périmètre **strictement local** : aucun `push`. `develop` local est en avance de 58 commits sur `origin/develop` — je ne pousse rien sans ta validation explicite.\n\nProchaines options possibles, à ta main : suppression de `feature/agent-session-limits`, et/ou push de `develop` vers origin (action sortante → nécessite ton feu vert)."}

.ideai/conversations/6ffc1f69-77a5-0da1-1965-ef26d1df72f5/handoff.md

@@ -0,0 +1,9 @@
+---
+upTo: 88f405da-f9c9-44bb-96c9-7e1b0e5af557
+objective: Bonjour TestConversation. Ceci est un test de communication inter-agents via IdeA. Peux-tu confirmer que tu me reçois et me dire combien font 17 + 25 ?
+---
+**Objectif :** Bonjour TestConversation. Ceci est un test de communication inter-agents via IdeA. Peux-tu confirmer que tu me reçois et me dire combien font 17 + 25 ?
+
+- **Prompt:** Bonjour TestConversation. Ceci est un test de communication inter-agents via IdeA. Peux-tu confirmer que tu me reçois et me dire combien font 17 + 25 ?
+- **Prompt:** Test de communication inter-agent. Merci de confirmer que tu reçois bien ce message en répondant via idea_reply avec : (1) un court message de confirmation, (2) la date/heure si tu y as accès, (3) le nom de ton AI Profile/contexte tel que tu le perçois. Ceci sert uniquement à valider le canal de communication entre agents IdeA.
+- **Response:** (1) Confirmation : message bien reçu, le canal de communication inter-agent IdeA fonctionne correctement. (2) Date : 2026-06-13 (je n'ai pas d'heure horodatée plus précise dans mon contexte). (3) AI Profile/contexte perçu : Claude Code (modèle Opus 4.8, claude-opus-4-8), opérant sur le project root /home/anthony/Documents/Projects/IdeA via un run dir isolé. Canal validé. ✅

.ideai/conversations/6ffc1f69-77a5-0da1-1965-ef26d1df72f5/log.jsonl

@@ -0,0 +1,3 @@
+{"id":"20dd8bdc-f858-46a6-9c8a-6afde591a6bd","conversation":"6ffc1f69-77a5-0da1-1965-ef26d1df72f5","atMs":1781367769591,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Bonjour TestConversation. Ceci est un test de communication inter-agents via IdeA. Peux-tu confirmer que tu me reçois et me dire combien font 17 + 25 ?"}
+{"id":"0b8fcc51-c692-4928-9d90-3823857dad5c","conversation":"6ffc1f69-77a5-0da1-1965-ef26d1df72f5","atMs":1781368607174,"source":{"kind":"agent","agentId":"a6ced819-b893-4213-b003-9e9dc79b9641"},"role":"prompt","text":"Test de communication inter-agent. Merci de confirmer que tu reçois bien ce message en répondant via idea_reply avec : (1) un court message de confirmation, (2) la date/heure si tu y as accès, (3) le nom de ton AI Profile/contexte tel que tu le perçois. Ceci sert uniquement à valider le canal de communication entre agents IdeA."}
+{"id":"88f405da-f9c9-44bb-96c9-7e1b0e5af557","conversation":"6ffc1f69-77a5-0da1-1965-ef26d1df72f5","atMs":1781368615582,"source":{"kind":"agent","agentId":"c932c770-cf36-4fb2-a966-71bb1644e4b4"},"role":"response","text":"(1) Confirmation : message bien reçu, le canal de communication inter-agent IdeA fonctionne correctement. (2) Date : 2026-06-13 (je n'ai pas d'heure horodatée plus précise dans mon contexte). (3) AI Profile/contexte perçu : Claude Code (modèle Opus 4.8, claude-opus-4-8), opérant sur le project root /home/anthony/Documents/Projects/IdeA via un run dir isolé. Canal validé. ✅"}

.ideai/conversations/dd35eeb0-2329-0dfa-3255-df7dba90a0aa/handoff.md

@@ -0,0 +1,7 @@
+---
+upTo: 419c60a5-2aca-4711-ad83-0a185bb3214e
+objective: Ping de test inter-agent depuis DevBackend — réponds avec un court PONG et l'heure que tu vois.
+---
+**Objectif :** Ping de test inter-agent depuis DevBackend — réponds avec un court PONG et l'heure que tu vois.
+
+- **Prompt:** Ping de test inter-agent depuis DevBackend — réponds avec un court PONG et l'heure que tu vois.

.ideai/conversations/dd35eeb0-2329-0dfa-3255-df7dba90a0aa/log.jsonl

@@ -0,0 +1 @@
+{"id":"419c60a5-2aca-4711-ad83-0a185bb3214e","conversation":"dd35eeb0-2329-0dfa-3255-df7dba90a0aa","atMs":1781427081894,"source":{"kind":"agent","agentId":"73c853d1-c0fd-463b-ad17-1d24fefa371f"},"role":"prompt","text":"Ping de test inter-agent depuis DevBackend — réponds avec un court PONG et l'heure que tu vois."}

.ideai/layouts.json

@@ -0,0 +1,129 @@
+{
+  "version": 1,
+  "activeId": "dd38b8ed-7199-48a6-a63f-1d1462ca6a34",
+  "layouts": [
+    {
+      "id": "dd38b8ed-7199-48a6-a63f-1d1462ca6a34",
+      "name": "Default",
+      "kind": "terminal",
+      "tree": {
+        "root": {
+          "type": "split",
+          "node": {
+            "id": "bd3dfce4-d31b-44d4-bd1e-b299b00d3cce",
+            "direction": "row",
+            "children": [
+              {
+                "node": {
+                  "type": "split",
+                  "node": {
+                    "id": "cd60658c-8c2d-4ef1-9149-073230350696",
+                    "direction": "column",
+                    "children": [
+                      {
+                        "node": {
+                          "type": "leaf",
+                          "node": {
+                            "id": "14d20dcb-f243-4381-a130-2d4d3d224f42",
+                            "session": "adb24405-26ad-4920-a114-d27a21d9022a",
+                            "agent": "a6ced819-b893-4213-b003-9e9dc79b9641",
+                            "agentWasRunning": true
+                          }
+                        },
+                        "weight": 1.1910967
+                      },
+                      {
+                        "node": {
+                          "type": "leaf",
+                          "node": {
+                            "id": "8d2c2720-b971-4792-8c0a-b28581eea8a8",
+                            "session": "5def4f66-2921-4ddc-b9a2-be4958788081"
+                          }
+                        },
+                        "weight": 0.80890334
+                      }
+                    ]
+                  }
+                },
+                "weight": 1.0
+              },
+              {
+                "node": {
+                  "type": "split",
+                  "node": {
+                    "id": "80fa1a60-60d7-4442-8614-fb055ea97e93",
+                    "direction": "column",
+                    "children": [
+                      {
+                        "node": {
+                          "type": "leaf",
+                          "node": {
+                            "id": "fbcfacb2-ad0b-46cc-9b53-8199d23f9324",
+                            "session": "462f69bc-7957-437d-9096-e79b57af1223",
+                            "agent": "73c853d1-c0fd-463b-ad17-1d24fefa371f",
+                            "agentWasRunning": true
+                          }
+                        },
+                        "weight": 0.80238867
+                      },
+                      {
+                        "node": {
+                          "type": "split",
+                          "node": {
+                            "id": "8318f2b8-55e1-4fff-88ba-9891bd85c8a0",
+                            "direction": "column",
+                            "children": [
+                              {
+                                "node": {
+                                  "type": "leaf",
+                                  "node": {
+                                    "id": "07698ab4-0700-4205-966b-a50b1e73ec2b",
+                                    "session": "f1780cb6-91c3-47d7-9081-1bcbdb96ba92",
+                                    "agent": "cd0b4cf1-1bef-4fae-ade5-f0a6b49bbaf5",
+                                    "agentWasRunning": true
+                                  }
+                                },
+                                "weight": 1.0
+                              },
+                              {
+                                "node": {
+                                  "type": "leaf",
+                                  "node": {
+                                    "id": "f31fa71f-c55e-4597-8ea0-caa9775531ff",
+                                    "session": "b04d11d9-0359-48a6-94ec-bd1d40eb6277",
+                                    "agent": "aefdbd61-e3d4-4bc1-9f42-c259446a97b5",
+                                    "agentWasRunning": true
+                                  }
+                                },
+                                "weight": 1.0
+                              }
+                            ]
+                          }
+                        },
+                        "weight": 1.1976112
+                      }
+                    ]
+                  }
+                },
+                "weight": 1.0
+              }
+            ]
+          }
+        }
+      }
+    },
+    {
+      "id": "a1958c6d-901f-4fbc-a621-d026aa6b2b62",
+      "name": "Git Graph",
+      "kind": "gitGraph",
+      "tree": {
+        "root": {
+          "type": "leaf",
+          "node": {
+            "id": "7a088843-00e7-4ea0-9676-8c4acb1f6d1d"
+          }
+        }
+      }
+    }
+  ]
+}

.ideai/memory/MEMORY.md

@@ -7,61 +7,3 @@
 - [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/appimage-build-no-strip-relr-dyn-fix.md

@@ -1,52 +0,0 @@
----
-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

@@ -1,44 +0,0 @@
----
-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

@@ -1,21 +0,0 @@
----
-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

@@ -1,28 +0,0 @@
----
-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

@@ -1,30 +0,0 @@
----
-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

@@ -1,118 +0,0 @@
----
-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

@@ -1,29 +0,0 @@
----
-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

@@ -1,49 +0,0 @@
----
-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

@@ -1,26 +0,0 @@
----
-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

@@ -1,52 +0,0 @@
----
-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

@@ -1,13 +0,0 @@
----
-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

@@ -1,17 +0,0 @@
----
-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

@@ -1,50 +0,0 @@
----
-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

@@ -1,11 +0,0 @@
----
-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

@@ -1,14 +0,0 @@
----
-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

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

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

@@ -1,22 +0,0 @@
----
-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

@@ -1,40 +0,0 @@
----
-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

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

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

@@ -1,14 +0,0 @@
----
-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

@@ -1,67 +0,0 @@
----
-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

@@ -1,79 +0,0 @@
----
-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

@@ -1,78 +0,0 @@
----
-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

@@ -1,15 +0,0 @@
----
-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

@@ -1,21 +0,0 @@
----
-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/opencode-llamacpp-replaces-ollama.md

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

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

@@ -1,37 +0,0 @@
----
-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

@@ -1,14 +0,0 @@
----
-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

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

.ideai/memory/skills-integration-canonical-foundation.md

@@ -1,11 +0,0 @@
----
-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

@@ -1,23 +0,0 @@
----
-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

@@ -1,17 +0,0 @@
----
-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

@@ -1,19 +0,0 @@
----
-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

@@ -1,19 +0,0 @@
----
-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

@@ -1,19 +0,0 @@
----
-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

@@ -1,17 +0,0 @@
----
-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

@@ -1,64 +0,0 @@
----
-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

@@ -1,29 +0,0 @@
----
-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

@@ -1,9 +0,0 @@
----
-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

@@ -1,28 +0,0 @@
----
-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

@@ -1,11 +0,0 @@
----
-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

@@ -1,17 +0,0 @@
----
-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

@@ -1,19 +0,0 @@
----
-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

@@ -1,18 +0,0 @@
----
-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

@@ -1,25 +0,0 @@
----
-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

@@ -1,20 +0,0 @@
----
-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

@@ -1,15 +0,0 @@
----
-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

@@ -1,19 +0,0 @@
----
-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

@@ -1,16 +0,0 @@
----
-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

@@ -1,18 +0,0 @@
----
-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

@@ -1,15 +0,0 @@
----
-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

@@ -1,15 +0,0 @@
----
-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

@@ -1,15 +0,0 @@
----
-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

@@ -1,19 +0,0 @@
----
-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

@@ -1,23 +0,0 @@
----
-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

@@ -1,39 +0,0 @@
----
-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

@@ -1,44 +0,0 @@
----
-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

@@ -1,15 +0,0 @@
----
-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

@@ -34,159 +34,5 @@
       }
     ],
     "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

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

@@ -1,42 +0,0 @@
-# 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/sprints/028179b1-eaf4-41e9-9c1f-7c37125117e6/sprint.md

@@ -1,11 +0,0 @@
----
-id: "028179b1-eaf4-41e9-9c1f-7c37125117e6"
-order: 2
-name: "Client - serveur"
-status: "planned"
-createdBy: {"kind":"user"}
-updatedBy: {"kind":"user"}
-createdAt: 1783329381447
-updatedAt: 1783330421737
-version: 4
----

.ideai/sprints/5afd6780-0f76-40d7-a10f-32ee52469d74/sprint.md

@@ -1,11 +0,0 @@
----
-id: "5afd6780-0f76-40d7-a10f-32ee52469d74"
-order: 1
-name: "UI rework"
-status: "planned"
-createdBy: {"kind":"user"}
-updatedBy: {"kind":"user"}
-createdAt: 1783329530306
-updatedAt: 1783330421736
-version: 3
----

.ideai/sprints/883534aa-7fc1-4d83-a9c0-17cac4a4eea5/sprint.md

@@ -1,11 +0,0 @@
----
-id: "883534aa-7fc1-4d83-a9c0-17cac4a4eea5"
-order: 4
-name: "Modeles locaux"
-status: "planned"
-createdBy: {"kind":"user"}
-updatedBy: {"kind":"user"}
-createdAt: 1783757092388
-updatedAt: 1783757205620
-version: 2
----

.ideai/sprints/d8f3f37b-87ca-4509-9116-45a99bc711df/sprint.md

@@ -1,11 +0,0 @@
----
-id: "d8f3f37b-87ca-4509-9116-45a99bc711df"
-order: 3
-name: "Session limites handle"
-status: "planned"
-createdBy: {"kind":"user"}
-updatedBy: {"kind":"user"}
-createdAt: 1783329454681
-updatedAt: 1783330421738
-version: 3
----

.ideai/sprints/e28a4d53-8bd2-446a-b0ac-2a017373b8b2/sprint.md

@@ -1,11 +0,0 @@
----
-id: "e28a4d53-8bd2-446a-b0ac-2a017373b8b2"
-order: 5
-name: "Gestion des bugs"
-status: "planned"
-createdBy: {"kind":"user"}
-updatedBy: {"kind":"user"}
-createdAt: 1783923775150
-updatedAt: 1783923775150
-version: 1
----

.ideai/sprints/index.json

@@ -1,50 +0,0 @@
-{
-  "version": 1,
-  "sprints": [
-    {
-      "id": "5afd6780-0f76-40d7-a10f-32ee52469d74",
-      "path": "5afd6780-0f76-40d7-a10f-32ee52469d74",
-      "order": 1,
-      "name": "UI rework",
-      "status": "planned",
-      "updatedAt": 1783330421736,
-      "version": 3
-    },
-    {
-      "id": "028179b1-eaf4-41e9-9c1f-7c37125117e6",
-      "path": "028179b1-eaf4-41e9-9c1f-7c37125117e6",
-      "order": 2,
-      "name": "Client - serveur",
-      "status": "planned",
-      "updatedAt": 1783330421737,
-      "version": 4
-    },
-    {
-      "id": "d8f3f37b-87ca-4509-9116-45a99bc711df",
-      "path": "d8f3f37b-87ca-4509-9116-45a99bc711df",
-      "order": 3,
-      "name": "Session limites handle",
-      "status": "planned",
-      "updatedAt": 1783330421738,
-      "version": 3
-    },
-    {
-      "id": "883534aa-7fc1-4d83-a9c0-17cac4a4eea5",
-      "path": "883534aa-7fc1-4d83-a9c0-17cac4a4eea5",
-      "order": 4,
-      "name": "Modeles locaux",
-      "status": "planned",
-      "updatedAt": 1783757205620,
-      "version": 2
-    },
-    {
-      "id": "e28a4d53-8bd2-446a-b0ac-2a017373b8b2",
-      "path": "e28a4d53-8bd2-446a-b0ac-2a017373b8b2",
-      "order": 5,
-      "name": "Gestion des bugs",
-      "status": "planned",
-      "updatedAt": 1783923775150,
-      "version": 1
-    }
-  ]
-}

.ideai/tickets/1/carnet.md

@@ -1,29 +0,0 @@
----
-issueRef: "#1"
-version: 11
-updatedBy: {"kind":"user"}
-updatedAt: 1783175265022
----
-- Cadrage: background-tasks-first-class-design. Arbitrage 5 écarts: b8-arbitration-outcomes.
-- FAIT B8 runner PTY + boucle sink fermée + refactor point-2. QA vert. Commit backend 8cac147.
-- FAIT UI cancel/retry câblés (cancel_background_task/retry_background_task). Commit frontend c179f93.
-- FAIT déclencheur in-app: surface MCP idea_run_in_background (BE-1+BE-2), commit f08dae6. Ferme l'écart de périmètre « aucun producteur ».
-- Dette tracée: #2 (PtyPort::wait + tee live), #3 (persistance sûre invocation/retry-after-reboot + énumération store), #5 (contrat DTO work-state).
-
-## MAJ 2026-07-04 — part autonome de #1 clôturée (Main)
-- AppImage rebuild frais confirmé (build 2026-07-03 23:56 > dernier source 23:53), inclut T1+T3, NO_STRIP=true.
-- VALIDATION AUTOMATISÉE VERTE : cargo build --workspace OK ; cargo test -p application / -p app-tauri / -p infrastructure = 0 failed ; frontend npm run build OK + vitest 459/460. L'unique rouge = flake de timing src/features/permissions/permissions.test.tsx (passe en isolation 2/2, non touché par #1, pas une régression).
-- COMMITS Git sur feature/background-tasks-first-class : eb9cc16 (code T1+T3, 21 fichiers) + ebd992e (19 notes mémoire + MEMORY.md). AUCUN merge vers develop. Runtime .ideai/{background-tasks,proposals,tickets}/ volontairement non commités.
-
-## ⚠️ MAJ 2026-07-04 — IMPACT TOPOLOGIE (constat Git, cadrage #4)
-- `feature/background-tasks-first-class` (#1) est DÉRIVÉE du `develop` ANORMAL/rembobiné (merge-base #1↔main = 1fc7869, pré-canonique ; a9653bc tip develop est ancêtre de #1). Donc #1 = baseline PRÉ-CANONIQUE (spawn_turn=0, run_turn batch, pas d'AgentTurnEvent).
-- La vraie ligne d'intégration est `main` (canonique, release ~01/07), PAS le develop rembobiné (18 commits en retard sur main). ⇒ la cible de merge « → develop » prévue au point 3 ci-dessous est INVALIDÉE.
-- #1 modifie massivement les fichiers divergés côté canonique : orchestrator/service.rs +425, domain/events.rs +184, lifecycle.rs +83, session/codex.rs. ⇒ portage sur canonique = CONFLITS NON TRIVIAUX attendus, pas un simple changement de cible.
-- PLAN Git (Phase C, à faire quand on reprendra #1) : branche fraîche `feature/background-tasks-first-class-canonical` depuis main + cherry-pick séquentiel des 17 commits (ancienne branche gardée comme filet), conflits sémantiques service/events escaladés à DevBackend/Architect, puis QA avant tout merge.
-- Décision de reconstruction de `develop` sur `main` : DESTRUCTIVE (rewrite branche partagée) → en attente validation utilisateur.
-
-## RESTE — DÉPENDANT UTILISATEUR (Main ne peut pas seul)
-1. Re-QA LIVE T3 : relancer l'AppImage fraîche puis vérifier onglet Work → Cancel/Retry (T3-a..f du cadrage workstate-background-tasks-projection-fix). QA non pilotable depuis sandbox → besoin app lancée.
-2. T2 — reconcile après reboot (fin AVANT wake), protocole MANUEL, coordination reboot utilisateur.
-3. [CIBLE À REVOIR] merge de #1 : ne plus viser le develop rembobiné. Porter #1 sur canonique (Phase C ci-dessus) PUIS merger vers develop-reconstruit/main. Dépend de la décision de reconstruction de develop.
-Main travaille sur #4 (annonces inter-agent) en attendant la dispo utilisateur pour 1-2-3.

.ideai/tickets/1/issue.md

@@ -1,24 +0,0 @@
----
-id: "ec19c041-7a44-456d-994d-f0dcb7c52f39"
-number: 1
-title: "Tâches de fond — finaliser B8 (runner PTY) et clôturer le chantier"
-status: "closed"
-priority: "medium"
-links: []
-agentRefs: [{"agentId":"a6ced819-b893-4213-b003-9e9dc79b9641","role":"assigned"}]
-createdBy: {"kind":"user"}
-updatedBy: {"kind":"user"}
-createdAt: 1783026129089
-updatedAt: 1783175265022
-version: 11
----
-Description :
-
-Le chantier « tâches de fond de 1re classe » est livré et QA-vert jusqu'à B7 inclus (mailbox bornée, rendez-vous inter-agent comme tâche durable, reconcile au boot, réveil du propriétaire, UI F1–F4). Commité sur feature/background-tasks-first-class (e05edc6 backend, 5d88c95 frontend), non mergé. Reste à fermer les points suivants avant de considérer le chantier terminé.
-
-Reste à faire :
-
-- [ ] B8 — runner de commandes couplé PTY : créer un BackgroundTask{kind: Command} au spawn d'une commande longue (côté pty.rs / LocalProcessSpawner) et pousser exit/stdout/stderr dans le completion sink. C'est ce qui active le flux run_in_background complet : une commande qui finit après la fin du tour de l'agent réveille automatiquement son propriétaire avec le résultat. Aujourd'hui le sink est prêt mais aucun runner concret ne s'y abonne.
-- [ ] UI cancel / retry des tâches de fond : les boutons existent mais sont désactivés faute de commande Tauri. Exposer cancel/retry (dépend de B8) et brancher l'UI.
-- [ ] Validation live end-to-end de la feature dans l'app réelle : lancer un build/commande longue en run_in_background, laisser le tour se terminer, vérifier que le propriétaire est bien re-réveillé avec le résultat (et idem après redémarrage d'IdeA entre la fin et le wake — le reconcile doit retrouver la complétion).
-- [ ] Merge feature/background-tasks-first-class → develop (sur validation) : résorbe aussi les 4 tests de protocole MCP périmés qui sont encore rouges sur develop (le fix d'alignement vit sur cette branche).