Files
IdeA/.ideai/tickets/186/carnet.md

2.3 KiB

issueRef, version, updatedBy, updatedAt
issueRef version updatedBy updatedAt
#186 3
kind agent_id
agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d
1786620908484

2026-08-13 — cadrage initial

Constat utilisateur

  • Les messages de progress dans la CLI custom semblent n'apparaître qu'au moment d'un tool/MCP, pas au moment où l'agent les émet.
  • Le progress est dupliqué au lieu d'évoluer de running vers done.
  • Les fichiers/images collés n'affichent plus de référence textuelle exploitable dans le chat.
  • /tmp n'est pas viable pour les gros artefacts ; besoin d'un tmp partagé géré par IdeA.
  • Le chat custom doit être agrandissable, taille actuelle conservée par défaut.

Cadrage UX

  • Une seule ligne de statut active par tour ; progress agent prioritaire, tool en fallback, done remplace running.
  • Les attachments doivent être affichés comme appendice compact du message, avec ref type [file 1]/[image 1].
  • Le chat doit être redimensionnable par poignée, avec reset et bornes.

Cadrage architecte

  • Le flux structuré possède déjà ReplyEvent/ReplyProgress/ChatBridge/CustomAgentChatView ; vérifier projection et corrélation plutôt que refondre.
  • Probable manque de contrat d'identité stable des progress items ; prévoir upsert par progress_id plutôt qu'heuristique par label.
  • La projection textuelle [file N] doit devenir canonique côté backend au moment du submit du tour, puis persistée dans le transcript et propagée au runtime.
  • Le tmp partagé doit être une ressource gouvernée par IdeA via handles opaques + leases + GC, pas un path libre.
  • La taille du chat custom doit rester un état frontend local à la cellule, pas un état de layout métier.

Constat lecture code rapide

  • Recherche source : ReplyProgress/send_with_tap/CustomAgentChatView/attachments présents dans le code.
  • Il existe des tests front nommés autour des labels d'attachments dans CustomAgentChatView, ce qui suggère une régression ou une projection rompue.
  • Il existe aussi des tests backend/runtime sur send_with_tap live pour Codex/OpenCode ; vérifier si le provider de la CLI custom suit bien le contrat ou si l'UI ne projette pas certains progress avant tool activity.

Prochaine étape

  • Demander à Git la branche de travail.
  • Faire diagnostiquer précisément par DevFrontend/DevBackend la cause réelle sur les 5 sujets avant implémentation.