IdeA/.ideai/tickets/171/carnet.md

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#171	3	kind agent_id agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d	1786378881038

Journal d'itération (le plus récent en haut)

Itération 1 — 2026-08-10 — Ouverture du cycle live progress depuis régression AppImage CLI custom

Signal utilisateur (capture live du 2026-08-10) : sur la custom CLI, tous les messages d'intention/progression de l'agent ne semblent pas remonter pendant le tour. Suspicion forte d'un trou avant le premier appel MCP (idea_ask_agent), alors que l'agent a vraisemblablement déjà émis des progress du type "Je vais d'abord regarder la liste de tools MCP...". En parallèle, des cartes tool/MCP apparaissent en double ; ce point de rendu est traité en articulation avec #157.

Rôle de #171 dans le cycle

Ce ticket porte la pipeline d'observabilité conversationnelle live entre le backend (ReplyEvent::Progress, ReplyChunk::Progress, événements de tool/delegation observables localement) et la surface UI/CLI. Il ne porte pas la cosmétique visuelle elle-même, mais la garantie que l'UI reçoive effectivement les événements non terminaux en temps réel, sans attendre Final.

Arbitrage de cycle

• #157 : rendu/dédoublonnage/hierarchie visuelle de la custom CLI pour les cartes tool/MCP/delegation.
• #171 : vérifier et, si nécessaire, corriger la chaîne backend -> transport -> store UI pour les progress/messages d'intention qui devraient apparaître avant le premier appel MCP.
• #167 : reste fermé tant qu'aucune preuve ne montre un nouveau défaut backend d'ordering/post-Final distinct du bug déjà corrigé.

Mandats actifs

• DevBackend : vérifier si les progress pré-MCP existent déjà dans le flux backend live pour le profil et la surface testés, et identifier tout buffer/relais/filtrage qui empêcherait leur projection temps réel.
• DevFrontend : vérifier si les ReplyChunk::Progress précoces arrivent mais sont ignorés, écrasés, réordonnés ou non rendus dans la custom CLI/store courant.
• QA : à venir après implémentation, avec scénario réel ciblant l'apparition d'un progress avant le premier MCP et l'absence de dépendance au Final pour l'affichage.

Critères d'acceptation de #171 pour ce cycle

• Un progress/message d'intention disponible dans le flux source apparaît dans l'UI/CLI avant le premier événement MCP, sans attendre la fin de tour.
• Aucun ReplyChunk::Progress légitime n'est perdu entre émission backend, transport et affichage.
• La limite provider est traitée honnêtement : si un provider n'émet rien avant le premier MCP, l'UI n'invente pas de faux message.
• Les preuves QA permettent de distinguer clairement un manque d'émission backend d'un simple problème de rendu frontend.