IdeA/.ideai/tickets/236/carnet.md

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#236	15	kind agent_id agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d	1787385802679

2026-08-21 Main

• Bug signalé: dans la custom CLI, la conversation s'affiche bien au début puis les progress, messages MCP et assimilés cessent de s'afficher au bout d'un moment.
• Architect: suspect prioritaire frontend, dans frontend/src/features/agents/CustomAgentChatView.tsx, autour de receive, foldChunk, appendProgress, progressUpsertKey, progressEntityKey.
• Hypothèse principale confirmée par DevFrontend: collisions de clé / upsert trop agressif sur progress tool/mcp sans progressId, causant des remplacements au lieu d'un enrichissement correct de l'historique visible.
• DevFrontend a corrigé la logique legacy: cycles successifs sans progressId restent visibles; completed finalise puis libère la clé active; doublons provider/IdeA d'une même complétion restent dédupliqués.
• Fichiers modifiés: frontend/src/features/agents/CustomAgentChatView.tsx, frontend/src/features/agents/CustomAgentChatView.test.tsx.
• QA: VERT. Commandes exécutées: npm test -- src/features/agents/CustomAgentChatView.test.tsx => 55/55 verts; npm test -- src/features/agents => 151/151 verts; npm run typecheck => OK.
• Git a commité le correctif: aaf628f fix(cli): préserve l'affichage des progress legacy sans progressId via clés d'occurrence dédiées — #236.
• Git a mergé localement le fix dans develop via --no-ff: 2c8c71c merge(cli): les messages progress/MCP ne disparaissent plus après un certain temps — #236 (QA verte).
• Aucun push effectué. Ticket clôturé.

2026-08-22 Main

• Réouverture du ticket pour un cas résiduel distinct observé utilisateur: un agent est en cours de travail mais le message MCP / l'annonce inter-agent attendu n'apparaît pas sur la surface des messages.
• UX: comportement attendu = preview côté demandeur + overlay côté cible visibles pendant le travail, puis purge à idle; après changement de projet, aucune fuite visuelle inter-projet, et réhydratation correcte dans le projet courant.
• Architect: diagnostic le plus probable = store/provider d'annonces non scopé par projectId; l'état app-global survit au switch, seedBusy n'hydrate que si absent, et un tour déjà en cours peut donc ne jamais remonter visuellement dans le nouveau projet.
• Correctif minimal demandé au frontend: reset + filter + rehydrate à chaque changement de projectId, idéalement avec un store project-scoped.
• Git: branche locale retenue fix/236-annonces-store-par-projectid depuis develop @ 85f659c.
• DevFrontend: diagnostic confirmé = provider app-global non borné par projet; correctif implémenté = provider explicitement borné par projectId, reset de index + busy au changement de projet, filtrage des agentAnnouncement par event.projectId, tests ciblés verts et npm run typecheck vert.
• Risque résiduel signalé par DevFrontend: agentBusyChanged ne porte pas encore projectId, donc le lifecycle live busy ne peut pas être filtré aussi strictement que les annonces; le bug visé est néanmoins corrigé par reset + réhydratation au switch.
• QA 2026-08-22: VERDICT VERT. Commandes validées: npm run test -- src/features/announcements/AnnouncementsProvider.test.tsx, npm run typecheck. Vérifications explicites: scénario resets and rehydrates when switching project vert; filtrage cross-project des agentAnnouncement vert; réhydratation d'un agent déjà busy dans le nouveau projet prouvée.
• Git 2026-08-22: commit local 8deaa1f fix(cli): store annonces inter-agent borné par projectId avec reset et réhydratation busy au changement de projet — #236; merge local --no-ff vers develop = 963b51a merge(cli): annonces inter-agent et messages MCP préservés après changement de projet — #236 (QA verte); aucun push.
• Risque/documentation: le flux agentBusyChanged sans projectId reste une limite de contrat; il n'a pas empêché la correction ciblée, mais peut justifier un ticket backend/frontend séparé si un cas réel de collision d'agentId inter-projets apparaît.