Blomios
ecad746c66
Rattrapage de l'état runtime .ideai/ (tickets #119-#139/#147 clôturés, compteur→149, ticket #148 clos et QA verte, métadonnées plugin android) — séparé du code de feature avant d'ouvrir le travail sur le nouveau bug de lancement CLI custom. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
95 lines
7.0 KiB
Markdown
95 lines
7.0 KiB
Markdown
---
|
|
issueRef: "#147"
|
|
version: 8
|
|
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
|
|
updatedAt: 1785924224928
|
|
---
|
|
## 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 custom` est `par cellule`, uniquement quand la cellule est sur un agent. En mode `Plain`, 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 `cancel` doit se comporter comme une interruption du tour courant (analogue à `Esc` dans 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 :
|
|
1. Robustesse
|
|
2. User experience
|
|
3. 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_view` persistant 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_view` avec migration douce (`Tui` par 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_agent` selon `preferred_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`, tests `application` ciblés layout, tests `infrastructure opencode`, tests `app-tauri` ciblés `dto_chat` / `chat_bridge`, `cargo fmt`.
|
|
|
|
### DevFrontend — état réel livré
|
|
- Livré :
|
|
- toggle `TUI native` / `CLI custom` par cellule agent seulement, selon compatibilité structured/headless.
|
|
- modale de confirmation de switch avec arrêt + relance et wording dynamique.
|
|
- vue `CustomAgentChatView` live en bulles user/agent, rendu défensif, mise en avant du `Final` via `Task Complete`.
|
|
- composer texte + pièce jointe via `pickFile()` + bouton `Cancel`.
|
|
- reattach live de session structurée si elle est encore vivante.
|
|
- câblage TS des méthodes `launchAgentChat`, `reattachAgentChat`, `sendAgentChat`, `closeAgentChat` côté ports/adapters/mock.
|
|
- 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 bouton `Cancel` ferme la session structurée via `closeAgentChat` au 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 run` a été exécuté par QA et est vert (`115` fichiers / `1083` tests).
|
|
- Côté Rust, QA n'a pas obtenu de preuve globale exploitable dans le sandbox à cause de contraintes d'environnement (`Read-only file system`, verrous `cargo`, 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.
|