docs(memory): nettoie la mémoire projet obsolète (#178)
- MEMORY.md : index des notes recentré - remaining-work-idea-agent-control-ide.md : réécriture alignée sur l'app actuelle - ui-rework-sprint-scoping-contracts.md : mise à jour - supprime 3 notes périmées : cycle-151-167-155-git-topology, develop-realigned-to-cli-ui-baseline-2026-07-02, ticket4-restart-on-develop-ebd992e Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@ -6,258 +6,70 @@ metadata:
|
||||
---
|
||||
# Remaining Work For IdeA Agent Control IDE
|
||||
|
||||
## Resume
|
||||
## Snapshot
|
||||
|
||||
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.
|
||||
Cette note remplace l'ancien état des lieux trop large et partiellement daté. Elle sert de
|
||||
point de reprise produit pour `Main` au **2026-08-11**.
|
||||
|
||||
See also:
|
||||
Voir aussi :
|
||||
|
||||
- `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.
|
||||
- `idea-product-directives-main-handoff` pour les priorités produit durables ;
|
||||
- `agent-context-memory-and-profile-handoff` pour les frontières contexte/mémoire/live-state ;
|
||||
- `live-state-persistence-program-closed-ls8` pour la base désormais livrée côté transcript/handoff/live-state.
|
||||
|
||||
Etat observe le 2026-06-11 sur le depot local:
|
||||
## Ce qui est désormais considéré comme acquis
|
||||
|
||||
- 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.
|
||||
- L'orchestration inter-agents IdeA fonctionne de bout en bout via les outils MCP du projet.
|
||||
- Le modèle de coordination `memory` / `handoff` / `log conversationnel` / `live-state` existe et est en production.
|
||||
- Les sessions structurées multi-profils, le custom CLI, les surfaces tickets, plugins et web ont une base réellement livrée.
|
||||
- La reprise technique par `conversationId` existe, mais la surface UX associée reste un choix produit, pas un invariant.
|
||||
|
||||
## Deja Livre Ou Tres Avance
|
||||
## Points encore ouverts au niveau produit
|
||||
|
||||
### 1. Artefacts projet dans `.ideai/`
|
||||
### 1. Fidélité de reprise conversationnelle côté surfaces humaines
|
||||
|
||||
- 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/`.
|
||||
Le backend sait reprendre une session et relire un transcript canonique. En revanche, la
|
||||
reconstruction de la conversation **dans les vues utilisateur** n'est pas homogène entre TUI,
|
||||
custom CLI et lecteurs dédiés. Le sujet ouvert n'est donc plus "est-ce qu'on sait reprendre ?"
|
||||
mais "quelle continuité visible veut-on montrer, et dans quelle surface ?".
|
||||
|
||||
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. Stabilisation UX du custom CLI
|
||||
|
||||
### 2. Memoire projet partagee
|
||||
Le custom CLI est une surface centrale mais encore mouvante :
|
||||
|
||||
- `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.
|
||||
- wording/tests de callouts ;
|
||||
- cohérence entre vue chat, TUI native et états busy ;
|
||||
- choix de ce qui doit être silencieux vs explicitement surfacé.
|
||||
|
||||
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.
|
||||
La suppression du popup de reprise par cellule va dans ce sens : réduire les affordances
|
||||
expérimentales tant qu'une continuité visible claire n'est pas décidée.
|
||||
|
||||
### 3. Contexte partage et contexte agent
|
||||
### 3. Curation de la mémoire projet
|
||||
|
||||
- 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.
|
||||
Le socle mémoire est livré, mais l'index et certaines notes dérivent avec le temps. Le besoin
|
||||
restant n'est plus la mécanique CRUD ; c'est la **curation** :
|
||||
|
||||
Conclusion: la separation `contexte projet` / `contexte agent` est en place.
|
||||
- retirer les notes historiques devenues trompeuses ;
|
||||
- conserver les décisions durables ;
|
||||
- maintenir `MEMORY.md` aligné avec les fichiers réellement utiles.
|
||||
|
||||
### 4. Messagerie inter-agents transparente
|
||||
### 4. Robustesse runtime et outillage partagé
|
||||
|
||||
- `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.
|
||||
Plusieurs chantiers runtime restent importants pour la productivité réelle des agents :
|
||||
|
||||
Verification locale du 2026-06-11:
|
||||
- disponibilité du toolchain Rust/Tauri dans les environnements isolés ;
|
||||
- robustesse des sondes de vivacité et des reprises longues ;
|
||||
- stabilité des providers locaux/cloud OpenCode et de leur catalogue.
|
||||
|
||||
- `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
|
||||
Ces sujets ne remettent pas en cause l'architecture générale, mais ils influencent fortement la
|
||||
qualité d'exécution au quotidien.
|
||||
|
||||
Conclusion: le coeur de la communication inter-agents n'est plus un chantier de conception. Il est deja implementé et teste.
|
||||
## Règle de lecture pour Main
|
||||
|
||||
### 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
|
||||
- Ne plus utiliser cette note comme backlog exhaustif historique.
|
||||
- S'en servir comme **boussole produit courte**.
|
||||
- Pour une zone précise, relire d'abord la note mémoire spécialisée correspondante avant de
|
||||
planifier un lot.
|
||||
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user