1.6 KiB
1.6 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| ticket156-reply-progress-foundation | memory note ticket156-reply-progress-foundation |
|
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(ProviderNativevsIdeaLocal) +ReplyProgressKind(Turn,Message,Tool,Mcp,Other) +ReplyProgressStage(Started,Delta,Completed,Info) dansdomain::ports. ReplyEvent::Progress { progress }est explicitement non terminal ;ReadinessPolicyet les drains applicatifs continuent de donner autorite uniquement aReplyEvent::Finalpour la fin de tour.RateLimitedreste orthogonal/non terminal.- DTO transport :
ReplyChunk::Progress { progress }avec shape JSON camelCase, additive par rapport aux anciens chunks. agent_sendutilise maintenantAgentSession::send_with_tappour projeter best-effort les progress pendant quesendtourne ; leReplyStreamretourne par l'adapter reste le chemin autoritaire draine jusqu'auFinal.- Mapping adapters : Claude/Codex/OpenCode emettent des progress
ProviderNativepour les evenements natifs observables (turn/system/step/tool item). OpenAI-compatible emet des progressIdeaLocal/Mcpautour 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.