Implémente la vue chat structurée par cellule agent (toggle TUI/CLI custom, préférence persistée `preferred_view`, reattach live, composer + pièces jointes) avec le socle backend AgentSession/ChatBridge (UserPrompt, cancel_current_turn, routage interrupt_agent, commande cancel_agent_chat). Corrige le bug bloquant relevé par QA : le bouton Cancel de CustomAgentChatView interrompait tout le tour via closeAgentChat au lieu de n'annuler que le tour courant via cancelAgentChat, ce qui tuait la session contrairement au contrat produit validé. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
7.0 KiB
7.0 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||||
|---|---|---|---|---|---|---|---|
| #147 | 7 |
|
1785882543204 |
Cadrage consolidé
Intention produit
Créer une CLI custom alternative à la TUI native actuelle pour les cellules agent. Cette vue doit communiquer avec l'agent en headless et afficher une retranscription conversationnelle vivante de ce que fait l'agent, sans limiter ce qui fait la spécificité d'IdeA.
Références visuelles jointes : task_completed.jpg, Cline.png.
Décisions validées avec l'utilisateur
- Tous les agents IdeA sont dans le périmètre, car le mode headless est considéré comme un socle du produit.
- Le choix
TUI native/CLI customestpar cellule, uniquement quand la cellule est sur un agent. En modePlain, le terminal reste inchangé. - La TUI native reste le mode par défaut pour le moment.
- Le switch de mode est autorisé en cours de session, mais avec warning explicite et arrêt de la session courante pour éviter toute confusion utilisateur.
- Même logique quand on repasse de
CLI customàTUI native. - Le bouton
canceldoit se comporter comme une interruption du tour courant (analogue àEscdans Claude/Codex), sans tuer la session elle-même. - La vue custom est une retranscription live pendant la durée de vie de la session, comme la TUI actuelle ; ce n'est pas un transcript persistant indépendant.
- Si la session est toujours vivante quand on rouvre la cellule, on doit revoir l'historique live associé ; si la session est morte, non.
- On veut afficher un maximum de ce qui est exposé proprement par le headless : messages intermédiaires, progression, appels d'outils, édition de fichiers, final, etc. La règle est d'utiliser au maximum les features fournies par le headless, sans bricolage fragile.
- Si certains rendus avancés (ex. code avec syntax highlighting, détails riches de tool calls, etc.) ne peuvent pas être faits de manière propre et solide, ils ne doivent pas être forcés.
Arbitrage prioritaire
Ordre de priorité explicitement demandé par l'utilisateur :
- Robustesse
- User experience
- Beauté de la CLI
Position de cadrage
Ce ticket ne doit pas être traité comme un simple ticket UI : il implique un vrai contrat runtime/headless pour piloter et afficher une session agent structurée. Le rendu en bulles est secondaire par rapport à la solidité des événements exposés et de la bascule de mode.
Hypothèses de travail à privilégier
- S'appuyer sur le mode headless des agents et normaliser uniquement les événements réellement fiables.
- Prévoir une dégradation contrôlée quand un agent expose moins de richesse événementielle qu'un autre.
- Pour les fichiers joints, privilégier une solution robuste de staging temporaire par session si nécessaire, plutôt qu'un mécanisme dépendant du provider.
- Garder la CLI custom comme vue de session vivante, pas comme nouvelle source de vérité persistante.
Questions résiduelles à arbitrer techniquement pendant le cycle
- Contrat précis des événements normalisés côté IdeA (
message,tool_call,tool_result,file_edit,status,final, etc.). - Comportement exact du staging temporaire des fichiers joints : durée de vie, nettoyage, taille max, comportement si le fichier source change.
- UX précise du warning de bascule de mode et du redémarrage de session.
- Stratégie de dégradation contrôlée selon la richesse réellement exposée par chaque agent headless.
Exécution du cycle au 4 août 2026
Architect
- Architect a revu le code réel et a conclu qu'il existe déjà un socle backend de chat structuré (
AgentSession,ChatBridge,ReplyChunk,reattach_agent_chat) ; le ticket est donc une réintégration de la vue chat avec quelques compléments ciblés, pas une reconstruction complète. - Contrats proposés :
preferred_viewpersistant par cellule,cancel_current_turn()côtéAgentSession,ReplyChunk::UserPrompt, toggle par cellule agent, vue live seulement, pas de transcript persistant secondaire.
Git
- Branche de travail locale décidée par Git :
feature/ticket147-custom-chat-cli. - Base choisie :
develop. - Commit de bookkeeping déjà posé par Git :
efbd56a1 chore(tickets): sync carnets/issues #102/#141-#147 + agent glmopencode.
DevBackend — état réel livré
- Livré :
LeafCell.preferred_viewavec migration douce (Tuipar défaut).- mutation layout pour persister cette préférence.
ReplyChunk::UserPrompt+ ajout du prompt user dans le scrollback live.AgentSession::cancel_current_turn()avec défaut no-op.- implémentation concrète best-effort du cancel pour
OpenCodeSession. - routage
interrupt_agentselonpreferred_view. - commande Tauri
cancel_agent_chat(session_id).
- Limites explicitement laissées :
- pas de staging backend structuré des pièces jointes ; le frontend injecte actuellement le chemin dans le prompt.
- cancel concret non généralisé à tous les adapters.
- pas de nouvelle persistance de transcript hors session vivante.
- Tests annoncés verts par DevBackend :
cargo test -p domain, testsapplicationciblés layout, testsinfrastructure opencode, testsapp-tauriciblésdto_chat/chat_bridge,cargo fmt.
DevFrontend — état réel livré
- Livré :
- toggle
TUI native/CLI custompar cellule agent seulement, selon compatibilité structured/headless. - modale de confirmation de switch avec arrêt + relance et wording dynamique.
- vue
CustomAgentChatViewlive en bulles user/agent, rendu défensif, mise en avant duFinalviaTask Complete. - composer texte + pièce jointe via
pickFile()+ boutonCancel. - reattach live de session structurée si elle est encore vivante.
- câblage TS des méthodes
launchAgentChat,reattachAgentChat,sendAgentChat,closeAgentChatcôté ports/adapters/mock.
- toggle
- Limites explicitement laissées :
- pas de payload structuré pour les attachments ; chemin injecté dans le prompt.
- rendu limité aux chunks réellement exposés (
textDelta,toolActivity,final,error,userPrompt).
QA — verdict actuel
- Verdict QA au 4 août 2026 : ROUGE pour le MVP réellement livré.
- Finding bloquant principal : dans
CustomAgentChatView, le boutonCancelferme la session structurée viacloseAgentChatau lieu d'interrompre seulement le tour courant. Cela viole explicitement le contrat produit validé avec l'utilisateur. - Finding secondaire : absence de test de non-régression couvrant ce comportement
Cancel. - Côté frontend,
npx vitest runa été exécuté par QA et est vert (115fichiers /1083tests). - Côté Rust, QA n'a pas obtenu de preuve globale exploitable dans le sandbox à cause de contraintes d'environnement (
Read-only file system, verrouscargo, saturation temporaire/tmp).
État d'avancement
- Le cycle a été lancé et exécuté jusqu'à QA.
- Le ticket n'est pas encore validé parce qu'il reste un correctif frontend ciblé à livrer sur
Cancel, suivi d'une revalidation QA.