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

4.2 KiB

issueRef, version, updatedBy, updatedAt
issueRef version updatedBy updatedAt
#252 6
kind agent_id
agent a6c6ea12-bfc6-4bdc-8031-324102dfa34d
1787551571486

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.

Git — commits + merge local (2026-08-24, QA verte vérifiée)

Commits sur fix/252-custom-cli-second-request-streaming :

  • d553d13 fix(custom-cli): progression et messages d'outils restaurés au second tour — le projecteur ne retient plus les events de progress après le premier message, seuls Text/Error restent bufferisés — #252 (QA verte)
  • 23c47ea test(custom-cli): tests à deux callbacks couvrant le streaming progress/outils sur la seconde requête au même agent — #252 (QA verte)
  • 6becdf2 chore(tickets): synchro du store local — carnet et statut #252

Merge local : effectué — 4553e5d merge(custom-cli) --no-ff dans develop. develop est en avance sur origin/develop (203 commits) — aucun push, conformément à la règle.

Re-vérification indépendante par Git avant merge :

  • Frontend : CustomAgentChatView.test.tsx + wsLiveClient.chat.test.ts (src/adapters/http/) → 62 passed.
  • Backend : cargo test -p infrastructure --lib session::opencode → 21 passed en série (--test-threads=1, 2 runs), incluant le nouveau test de régression.

⚠ Signalement QA (suivi requis, hors blocage #252) : la suite opencode est flaky en parallèle — des tests ANCIENS à timing (seeded_session_ignores_and_does_not_capture_other_session_events, seeded_or_captured_session_id_is_passed_as_opencode_session_arg, …) échouent intermittemment sous charge parallèle (fixtures sleep + timeouts 500 ms), à chaque exécution sur des tests différents. Le fix et son nouveau test passent systématiquement. Recommandation : ticket dédié QA/DevBackend pour fiabiliser ces tests (timeouts ou sérialisation ciblée).