28 lines
4.1 KiB
Markdown
28 lines
4.1 KiB
Markdown
---
|
|
issueRef: "#236"
|
|
version: 15
|
|
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
|
|
updatedAt: 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. |