4.2 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||||
|---|---|---|---|---|---|---|---|
| #252 | 6 |
|
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 develop1f14217, lignage custom CLI#249/#251QA 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
developsans l'agent Git. Fusion locale décidée par Git après QA verte. scripts/restart-idea-over-ssh.shreste non suivi — ne pas le committer sur cette branche.
Architect — cadrage root cause (2026-08-24)
- Suspect principal :
crates/infrastructure/src/session/opencode.rs,LiveTurnProjectorpasse enhold_until_new_messagedès qu'unconversation_idexiste, donc typiquement au 2e tour. - Effet probable : si le 2e tour n'expose qu'un seul
message_idcourant, le projecteur bufferise tous lesstep_start/tool_use/textdanspendinget n'émet rien en live. - Le pipeline backend
send_with_taprend le tap live critique : quandhas_tap=true, le flux autoritaire ne garde plus queFinal|Error; si le tap n'émet rien, l'UI ne verra jamais lesprogress/ 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 seulmessage_idsur 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
finaldu 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 startedpuiscompletedsur le 2e tour. - Variante négative :
late progressdu 1er tour ignoré, vraiprogressdu 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 :
d553d13fix(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)23c47eatest(custom-cli): tests à deux callbacks couvrant le streaming progress/outils sur la seconde requête au même agent — #252 (QA verte)6becdf2chore(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).