Files
IdeA/.ideai/tickets/147/carnet.md
Blomios ecad746c66 chore(tickets): synchronise les statuts tickets et l'état plugin android
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>
2026-08-05 13:40:44 +02:00

7.0 KiB

issueRef, version, updatedBy, updatedAt
issueRef version updatedBy updatedAt
#147 8
kind agent_id
agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d
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.