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