---
issueRef: "#171"
version: 5
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
updatedAt: 1786380032763
---
# Journal d'itération (le plus récent en haut)

## Itération 2 — 2026-08-10 — Pipeline live corrigée pour Codex/custom CLI, QA verte ciblée, attente de preuve AppImage live

### Diagnostic final du cycle

Le soupçon utilisateur d'un trou avant le premier MCP était **fondé** côté backend Codex.

Le backend exposait bien certains `ReplyEvent::Progress` live (ex. `turn.started`), mais un `agent_message` d'intention avant `idea_ask_agent` pouvait être retenu comme candidat `Final` et ne jamais être projeté comme événement live si le tour continuait. En parallèle, certains événements tool/MCP Codex étaient doublés à la source parce qu'un `Progress` canonique cohabitait avec un `ToolActivity` de compatibilité.

### Correctif backend livré sur le périmètre `#171`

- Un `agent_message` pré-MCP devient désormais une `Announcement` dès qu'un événement suivant prouve que le tour continue, au lieu de rester un faux candidat `Final`.
- Les doublons `ToolActivity` de compatibilité sont supprimés quand un `ReplyEvent::Progress` canonique existe déjà pour l'événement concerné.
- Fichiers: `crates/infrastructure/src/session/codex.rs`, `crates/infrastructure/src/session/mod.rs`.

### Validation backend/transport

Commandes validées par QA:

- `CARGO_HOME=/tmp/idea-cargo-home cargo test -p infrastructure codex -- --nocapture` → **41 passed**
- `CARGO_HOME=/tmp/idea-cargo-home cargo test -p app-tauri --test chat_bridge -- --nocapture` → **25 passed**

Couvertures explicitement mentionnées par QA:

- le message d'intention pré-MCP est bien projeté avant le premier progress MCP quand le flux l'expose ;
- le tap live reste antérieur au `Final` ;
- les doublons `ToolActivity` / `Progress` ne survivent plus dans le transport canonique ;
- l'invariant d'un seul terminal `Final` reste préservé.

### Git / intégration locale

- Commit backend: `d6306bb5` — `fix(codex): intention pré-MCP reclassée en Announcement + doublon ToolActivity supprimé (#157 #171)`
- Commit miroir tickets: `1beeed8c` — `chore(tickets): sync miroir #157 #171 — QA verte ciblée (AppImage en attente)`
- Merge local vers `develop`: `fa613674` — `merge(codex/cli): cycle #157 #171 — dedup cartes tool/MCP + intention pré-MCP live`

### Réserve avant fermeture définitive

- Pas encore de validation live AppImage / UI bout-en-bout avec le binaire utilisateur final.
- Rouge Rust global préexistant et hors scope toujours présent: `crates/infrastructure/tests/mcp_server.rs:777` (37 tools attendus vs 38 exposés, `idea_context_update` en plus).

### Statut décidé

- Ticket placé en **QA** dans l'attente d'une preuve live AppImage.
- Si la vérification live confirme l'apparition du progress pré-MCP et l'ordre correct dans la vraie UI, le ticket pourra être fermé sans nouveau développement.

---

## 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.