chore(idea): bookkeeping #216 QA verte + clôtures #214/#215

.ideai/tickets/216/carnet.md

@@ -0,0 +1,40 @@
+---
+issueRef: "#216"
+version: 4
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedAt: 1786813039107
+---
+## Triage 2026-08-15
+- Symptôme rapporté: dans la CLI custom, impression qu'après le premier `Final`, il n'y a plus de progress remontés.
+- Références durables relues: `ticket156-reply-progress-foundation`, `opencode-streaming-progress-mcp-surfacing-157`.
+- Cadrage UX: si `Final` clôt strictement le tour, il faut garder des signaux persistants de session/activité; sinon la surface paraît morte.
+- Cadrage Architect: distinguer 1) progress réellement reçus après `Final` mais masqués par la vue, 2) événements post-tour passant par un autre canal, 3) rupture réelle du flux adapter/backend.
+- Périmètre d'investigation initial: `frontend/src/features/agents/CustomAgentChatView.tsx`, `crates/app-tauri/src/commands.rs`, `crates/app-tauri/src/chat.rs`, puis adaptateurs provider si nécessaire.
+- Branche locale créée par Git: `fix/216-custom-cli-progress-after-final` depuis `develop` @ `a369993` (`v0.13.0`).
+
+## Diagnostic DevFrontend
+- Bug confirmé côté frontend.
+- `CustomAgentChatView.tsx` ignorait tout chunk reçu après `final/error`, hors prompt utilisateur.
+- Correctif appliqué: les `progress` tardifs restent affichés comme activité séparée sans rouvrir le tour ni repasser le bouton en `Stop`.
+- Fichiers modifiés:
+  - `frontend/src/features/agents/CustomAgentChatView.tsx`
+  - `frontend/src/features/agents/CustomAgentChatView.test.tsx`
+- Tests DevFrontend:
+  - `npm test -- CustomAgentChatView.test.tsx` => OK (49 tests)
+  - `npm run typecheck` => OK
+
+## Diagnostic DevBackend
+- Pas de bug backend/transport confirmé.
+- Le contrat `Final` terminal reste cohérent: tap live/drain/settling n'émettent pas de `Progress` après `Final` comme flux de tour autoritaire.
+- Tests DevBackend:
+  - `cargo test -p app-tauri --test chat_bridge` => OK (31)
+  - `cargo test -p infrastructure send_with_tap` => OK (3)
+  - `cargo test -p infrastructure normal_completion_returns_exactly_one_terminal_final` => OK (1)
+- Conclusion: si l'UI montre ou masque une activité après `Final`, le correctif doit rester côté frontend, pas en backend.
+
+## Verdict QA
+- Verdict: VERT.
+- QA a ajouté une assertion explicite: un `progress` après `Final` s'affiche, le tour ne se rouvre pas, `Stop` reste absent, `Envoyer` reste disponible.
+- Tests QA:
+  - `npm test -- CustomAgentChatView.test.tsx` => OK
+  - `npm run typecheck` => OK

.ideai/tickets/216/issue.md

@@ -0,0 +1,17 @@
+---
+id: "81ef20fa-57bf-468c-b396-4f1ee2c61c08"
+number: 216
+title: "CLI custom: plus de progress remontés après le premier Final"
+status: "qa"
+priority: "high"
+sprint: null
+links: []
+agentRefs: []
+attachments: []
+createdBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
+createdAt: 1786812380073
+updatedAt: 1786813039107
+version: 4
+---
+Investigation et correction du comportement où la CLI custom semble ne plus afficher/remonter les événements de progression après un premier message Final. Vérifier si le bug est purement d'affichage ou si le flux de progress s'arrête réellement.