Blomios
ed58afa034
- 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>
86 lines
4.1 KiB
Markdown
86 lines
4.1 KiB
Markdown
---
|
|
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
|
|
|
|
## Snapshot
|
|
|
|
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**.
|
|
|
|
Voir aussi :
|
|
|
|
- `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.
|
|
|
|
## Ce qui est désormais considéré comme acquis
|
|
|
|
- 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.
|
|
|
|
## Points encore ouverts au niveau produit
|
|
|
|
### 1. Fidélité de reprise conversationnelle côté surfaces humaines
|
|
|
|
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 ?".
|
|
|
|
### 2. Stabilisation UX du custom CLI
|
|
|
|
Le custom CLI est une surface centrale mais encore mouvante :
|
|
|
|
- wording/tests de callouts ;
|
|
- cohérence entre vue chat, TUI native et états busy ;
|
|
- choix de ce qui doit être silencieux vs explicitement surfacé.
|
|
|
|
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. Curation de la mémoire projet
|
|
|
|
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** :
|
|
|
|
- retirer les notes historiques devenues trompeuses ;
|
|
- conserver les décisions durables ;
|
|
- maintenir `MEMORY.md` aligné avec les fichiers réellement utiles.
|
|
|
|
### 4. Robustesse runtime et outillage partagé
|
|
|
|
Plusieurs chantiers runtime restent importants pour la productivité réelle des agents :
|
|
|
|
- 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.
|
|
|
|
Ces sujets ne remettent pas en cause l'architecture générale, mais ils influencent fortement la
|
|
qualité d'exécution au quotidien.
|
|
|
|
## Règle de lecture pour Main
|
|
|
|
- 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.
|
|
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".
|