feat(agent): conversation par paire + entrée médiée + pivot terminal/MCP

Coeur inter-agents consolidé et surface front réalignée sur la décision
"terminal natif PTY, pas d'UI chat" (Option 1).

Domaine
- nouveaux modules conversation, mailbox, input, fileguard (ports + types)
- orchestrator/profile/events étendus (conversation par paire, FIFO)

Application / Infrastructure
- orchestrator/service + context_guard : sérialisation FIFO par agent,
  garde RW mémoire/contexte, dispatch ask/reply
- adapters in-memory conversation / mailbox / input / fileguard
- registry session + lifecycle agent durcis (1 agent = 1 session vivante)
- outils MCP idea_* alignés sur le nouveau dispatch

Frontend
- MediatedInput + useAgentBusy : entrée utilisateur médiée par IdeA,
  terminal = vue sortie inchangée
- suppression de la vue chat structurée (AgentChatView) — abandonnée
- adapter input + ports mis à jour

Divers
- .ideai/ : mémoire projet + briefs de cadrage versionnés ;
  requests/ runtime ignoré ; agents projet réels (DevBackend/DevFrontend/QA)

Tests : Rust (domain/application/infrastructure/app-tauri) + front (346) verts.

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

.ideai/memory/MEMORY.md

@@ -0,0 +1,5 @@
+# Memory Index
+
+- [agent-context-memory-and-profile-handoff](agent-context-memory-and-profile-handoff.md) — Decisions sur l'injection de contexte, la memoire durable, l'etat live et le handoff de profil entre agents IA.
+- [idea-product-directives-main-handoff](idea-product-directives-main-handoff.md) — Directives produit consolidees pour guider Main sur la robustesse, la persistance, le handoff cross-profile et la sobriete UX.
+- [remaining-work-idea-agent-control-ide](remaining-work-idea-agent-control-ide.md) — Etat des lieux des acquis et des chantiers restants pour aligner IdeA avec la cible d'IDE de controle d'agents IA.

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

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

.ideai/memory/idea-product-directives-main-handoff.md

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

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

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