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>
This commit is contained in:
273
.ideai/memory/remaining-work-idea-agent-control-ide.md
Normal file
273
.ideai/memory/remaining-work-idea-agent-control-ide.md
Normal file
@ -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".
|
||||
Reference in New Issue
Block a user