20 lines
1.6 KiB
Markdown
20 lines
1.6 KiB
Markdown
---
|
|
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. |