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