Rebase de l'état ticket (réouverture #102, clôtures #141-146, ouverture #147) et ajout du contexte agent glmopencode avant démarrage du cycle #147. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.5 KiB
3.5 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||||
|---|---|---|---|---|---|---|---|
| #147 | 6 |
|
1785880207496 |
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.