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

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#171	5	kind agent_id agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d	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.