---
issueRef: "#156"
version: 7
updatedBy: {"kind":"agent","agent_id":"1ff94b51-3e17-4a39-8543-7715d1ff0f80"}
updatedAt: 1786014830849
---
# Objectif

Fournir une fondation canonique permettant d'exposer **tous les progress/events non terminaux réellement mis à disposition** par les profils IA, avant `Final`, sans coupler le produit au format d'un provider particulier.

# Pourquoi

Le comportement observé sur la CLI custom montre que certains profils, notamment Codex, donnent aujourd'hui une impression de silence jusqu'au `Final`, puis affichent certains appels/outils après coup. Même si une partie du "thinking" interne reste potentiellement indisponible, IdeA doit au moins projeter de manière cohérente tout ce qui est effectivement observable.

# Portée attendue

- Définir une taxonomie canonique d'événements intermédiaires utilisable par le chat agent et l'inter-agent.
- Couvrir un maximum de profils IA : Codex, Claude, profils structured/OpenAI-like, et futurs profils.
- Prévoir une dégradation propre quand un profil n'expose que `turn.started`/`Final`, ou seulement quelques items/outils.
- Séparer clairement :
  - événements natifs du provider (text deltas, item started/completed, progress, etc.)
  - observabilité locale IdeA (ex. calls MCP/tooling orchestrés par IdeA)
- Préserver la robustesse : aucun affichage temps réel ne doit devenir autorité de fin de tour.

# Contraintes / garde-fous

- Ne jamais promettre le streaming du raisonnement interne si le provider ne l'expose pas explicitement.
- Les événements intermédiaires sont "best effort" ; `Final` reste l'unique sortie terminale métier.
- Le contrat doit être provider-agnostic côté domaine/application ; les adapters font le mapping.
- Les appels MCP/outils orchestrés par IdeA doivent être projetables même si le provider reste silencieux.

# Livrables attendus

- Contrat d'événements canonique + mapping par famille de profils.
- Stratégie de transport/projection live jusqu'au frontend.
- Inventaire des événements accessibles par profil et des trous assumés.
- Tests de non-régression sur l'absence de blocage/buffering terminal.

# Questions à arbitrer

- Quels événements deviennent de première classe dans le contrat canonique ?
- Quelle granularité conserver pour les tool/MCP calls (start/end seulement, ou payload résumé) ?
- Quelle source de vérité pour les événements locaux IdeA vs les événements natifs provider ?
- Quelle stratégie de batching/throttling pour éviter le bruit tout en gardant du temps réel utile ?

# Définition de done

- IdeA sait exposer, au fil de l'eau, le maximum d'événements disponibles sans attendre systématiquement `Final`.
- L'absence d'événements d'un provider est traitée comme une limite du provider, pas comme un bug UI.
- Le comportement est documenté profil par profil.