50 lines
2.8 KiB
Markdown
50 lines
2.8 KiB
Markdown
---
|
|
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. |