IdeA/.ideai/tickets/252/carnet.md

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#252	4	kind agent_id agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d	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.