chore(idea): bookkeeping .ideai — tickets #184-#207, contexts agents, mémoire (préparation train refonte web #202)

.ideai/tickets/186/carnet.md

@@ -0,0 +1,35 @@
+---
+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.