chore(tickets): synchro du store local — carnet et statut #252

.ideai/tickets/252/carnet.md

@@ -1,6 +1,32 @@
 ---
 issueRef: "#252"
-version: 1
+version: 4
 updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
-updatedAt: 1787550761371
+updatedAt: 1787551198700
 ---
+# Git — décision de branche (2026-08-24)
+
+- Branche de travail : `fix/252-custom-cli-second-request-streaming` (créée et checkout, base = tip develop `1f14217`, lignage custom CLI `#249/#251` QA verte inclus).
+- Dev : implémente le fix sur cette branche. Commits : `fix(custom-cli): … — #252`.
+- QA : tests fonctionnels réels sur la MÊME branche (deux requêtes successives au même agent custom CLI ; échec si progress/messages d'outils disparaissent au second tour). Commits : `test(custom-cli): … — #252`.
+- Interdits : aucun push distant ; pas de merge/rebase vers `develop` sans l'agent Git. Fusion locale décidée par Git après QA verte.
+- `scripts/restart-idea-over-ssh.sh` reste non suivi — ne pas le committer sur cette branche.
+
+# Architect — cadrage root cause (2026-08-24)
+
+- Suspect principal : `crates/infrastructure/src/session/opencode.rs`, `LiveTurnProjector` passe en `hold_until_new_message` dès qu'un `conversation_id` existe, donc typiquement au 2e tour.
+- Effet probable : si le 2e tour n'expose qu'un seul `message_id` courant, le projecteur bufferise tous les `step_start` / `tool_use` / `text` dans `pending` et n'émet rien en live.
+- Le pipeline backend `send_with_tap` rend le tap live critique : quand `has_tap=true`, le flux autoritaire ne garde plus que `Final|Error`; si le tap n'émet rien, l'UI ne verra jamais les `progress` / messages d'outils du 2e tour.
+- Le frontend n'est pas la cause racine principale.
+- Stratégie de fix minimale : corriger le seam OpenCode pour identifier le tour courant sans exiger un second basculement de `message_id`, puis ajouter une régression backend dédiée au cas « session existante + un seul `message_id` sur le nouveau tour ».
+
+# QA — audit de couverture (2026-08-24)
+
+- Les tests existants ne permettaient pas d'annoncer honnêtement vert sur ce bug.
+- Gap principal : pas de test fonctionnel réaliste avec deux callbacks de stream distincts et un vrai réarmement du 2e tour après le `final` du 1er.
+- Tests à exiger après fix :
+  - 2 requêtes successives avec nouveau callback de stream au 2e tour.
+  - Même outil entre les deux tours.
+  - Vérification d'un `progress started` puis `completed` sur le 2e tour.
+  - Variante négative : `late progress` du 1er tour ignoré, vrai `progress` du 2e tour affiché.
+- Ne pas revalider ce ticket sans preuve de commandes réelles et, si possible, scénario fonctionnel via harness custom CLI.