IdeA/.ideai/tickets/156/carnet.md

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#156	7	kind agent_id agent 1ff94b51-3e17-4a39-8543-7715d1ff0f80	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.