48 lines
4.2 KiB
Markdown
48 lines
4.2 KiB
Markdown
---
|
|
issueRef: "#252"
|
|
version: 6
|
|
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
|
|
updatedAt: 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).
|