---
issueRef: "#186"
version: 3
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
updatedAt: 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.