chore(tickets): clôture #151 #156 #157 #160 — sync tickets/mémoire (QA verte)

.ideai/tickets/156/carnet.md

@@ -0,0 +1,50 @@
+---
+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.