---
name: ticket156-reply-progress-foundation
description: memory note ticket156-reply-progress-foundation
metadata:
  type: project
---
# Ticket #156 — foundation canonique ReplyProgress

Type: reference

Phase 2 du cycle CLI custom a pose le contrat backend canonique des evenements intermediaires avant `Final`.

Decisions livrees :
- Domaine : `ReplyProgress` + `ReplyProgressSource` (`ProviderNative` vs `IdeaLocal`) + `ReplyProgressKind` (`Turn`, `Message`, `Tool`, `Mcp`, `Other`) + `ReplyProgressStage` (`Started`, `Delta`, `Completed`, `Info`) dans `domain::ports`.
- `ReplyEvent::Progress { progress }` est explicitement non terminal ; `ReadinessPolicy` et les drains applicatifs continuent de donner autorite uniquement a `ReplyEvent::Final` pour la fin de tour. `RateLimited` reste orthogonal/non terminal.
- DTO transport : `ReplyChunk::Progress { progress }` avec shape JSON camelCase, additive par rapport aux anciens chunks.
- `agent_send` utilise maintenant `AgentSession::send_with_tap` pour projeter best-effort les progress pendant que `send` tourne ; le `ReplyStream` retourne par l'adapter reste le chemin autoritaire draine jusqu'au `Final`.
- Mapping adapters : Claude/Codex/OpenCode emettent des progress `ProviderNative` pour les evenements natifs observables (turn/system/step/tool item). OpenAI-compatible emet des progress `IdeaLocal`/`Mcp` autour des appels d'outils orchestries par IdeA.

Garde-fous : ne pas promettre le streaming du raisonnement interne ; ne jamais parser les metadonnees provider comme autorite metier ; #157 doit consommer `ReplyChunk::Progress` cote UI pour affichage distinct et degrade proprement si absent.