Blomios
5269315421
- counter.json : nextNumber 173 -> 179 - index.json : ajoute #173 à #178 (tous closed) - dirs tickets/173-178 (carnet + issue) - carnets/issues #157 #171 mis à jour Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
81 lines
5.5 KiB
Markdown
81 lines
5.5 KiB
Markdown
---
|
|
issueRef: "#171"
|
|
version: 5
|
|
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
|
|
updatedAt: 1786380032763
|
|
---
|
|
# Journal d'itération (le plus récent en haut)
|
|
|
|
## Itération 2 — 2026-08-10 — Pipeline live corrigée pour Codex/custom CLI, QA verte ciblée, attente de preuve AppImage live
|
|
|
|
### Diagnostic final du cycle
|
|
|
|
Le soupçon utilisateur d'un trou avant le premier MCP était **fondé** côté backend Codex.
|
|
|
|
Le backend exposait bien certains `ReplyEvent::Progress` live (ex. `turn.started`), mais un `agent_message` d'intention avant `idea_ask_agent` pouvait être retenu comme candidat `Final` et ne jamais être projeté comme événement live si le tour continuait. En parallèle, certains événements tool/MCP Codex étaient doublés à la source parce qu'un `Progress` canonique cohabitait avec un `ToolActivity` de compatibilité.
|
|
|
|
### Correctif backend livré sur le périmètre `#171`
|
|
|
|
- Un `agent_message` pré-MCP devient désormais une `Announcement` dès qu'un événement suivant prouve que le tour continue, au lieu de rester un faux candidat `Final`.
|
|
- Les doublons `ToolActivity` de compatibilité sont supprimés quand un `ReplyEvent::Progress` canonique existe déjà pour l'événement concerné.
|
|
- Fichiers: `crates/infrastructure/src/session/codex.rs`, `crates/infrastructure/src/session/mod.rs`.
|
|
|
|
### Validation backend/transport
|
|
|
|
Commandes validées par QA:
|
|
|
|
- `CARGO_HOME=/tmp/idea-cargo-home cargo test -p infrastructure codex -- --nocapture` → **41 passed**
|
|
- `CARGO_HOME=/tmp/idea-cargo-home cargo test -p app-tauri --test chat_bridge -- --nocapture` → **25 passed**
|
|
|
|
Couvertures explicitement mentionnées par QA:
|
|
|
|
- le message d'intention pré-MCP est bien projeté avant le premier progress MCP quand le flux l'expose ;
|
|
- le tap live reste antérieur au `Final` ;
|
|
- les doublons `ToolActivity` / `Progress` ne survivent plus dans le transport canonique ;
|
|
- l'invariant d'un seul terminal `Final` reste préservé.
|
|
|
|
### Git / intégration locale
|
|
|
|
- Commit backend: `d6306bb5` — `fix(codex): intention pré-MCP reclassée en Announcement + doublon ToolActivity supprimé (#157 #171)`
|
|
- Commit miroir tickets: `1beeed8c` — `chore(tickets): sync miroir #157 #171 — QA verte ciblée (AppImage en attente)`
|
|
- Merge local vers `develop`: `fa613674` — `merge(codex/cli): cycle #157 #171 — dedup cartes tool/MCP + intention pré-MCP live`
|
|
|
|
### Réserve avant fermeture définitive
|
|
|
|
- Pas encore de validation live AppImage / UI bout-en-bout avec le binaire utilisateur final.
|
|
- Rouge Rust global préexistant et hors scope toujours présent: `crates/infrastructure/tests/mcp_server.rs:777` (37 tools attendus vs 38 exposés, `idea_context_update` en plus).
|
|
|
|
### Statut décidé
|
|
|
|
- Ticket placé en **QA** dans l'attente d'une preuve live AppImage.
|
|
- Si la vérification live confirme l'apparition du progress pré-MCP et l'ordre correct dans la vraie UI, le ticket pourra être fermé sans nouveau développement.
|
|
|
|
---
|
|
|
|
## Itération 1 — 2026-08-10 — Ouverture du cycle live progress depuis régression AppImage CLI custom
|
|
|
|
**Signal utilisateur (capture live du 2026-08-10)** : sur la custom CLI, tous les messages d'intention/progression de l'agent ne semblent pas remonter pendant le tour. Suspicion forte d'un trou avant le premier appel MCP (`idea_ask_agent`), alors que l'agent a vraisemblablement déjà émis des progress du type "Je vais d'abord regarder la liste de tools MCP...". En parallèle, des cartes tool/MCP apparaissent en double ; ce point de rendu est traité en articulation avec #157.
|
|
|
|
### Rôle de #171 dans le cycle
|
|
|
|
Ce ticket porte **la pipeline d'observabilité conversationnelle live** entre le backend (`ReplyEvent::Progress`, `ReplyChunk::Progress`, événements de tool/delegation observables localement) et la surface UI/CLI. Il ne porte pas la cosmétique visuelle elle-même, mais la garantie que l'UI reçoive effectivement les événements non terminaux en temps réel, sans attendre `Final`.
|
|
|
|
### Arbitrage de cycle
|
|
|
|
- **#157** : rendu/dédoublonnage/hierarchie visuelle de la custom CLI pour les cartes tool/MCP/delegation.
|
|
- **#171** : vérifier et, si nécessaire, corriger la chaîne backend -> transport -> store UI pour les progress/messages d'intention qui devraient apparaître avant le premier appel MCP.
|
|
- **#167** : reste fermé tant qu'aucune preuve ne montre un nouveau défaut backend d'ordering/post-Final distinct du bug déjà corrigé.
|
|
|
|
### Mandats actifs
|
|
|
|
- **DevBackend** : vérifier si les progress pré-MCP existent déjà dans le flux backend live pour le profil et la surface testés, et identifier tout buffer/relais/filtrage qui empêcherait leur projection temps réel.
|
|
- **DevFrontend** : vérifier si les `ReplyChunk::Progress` précoces arrivent mais sont ignorés, écrasés, réordonnés ou non rendus dans la custom CLI/store courant.
|
|
- **QA** : à venir après implémentation, avec scénario réel ciblant l'apparition d'un progress avant le premier MCP et l'absence de dépendance au `Final` pour l'affichage.
|
|
|
|
### Critères d'acceptation de #171 pour ce cycle
|
|
|
|
- Un progress/message d'intention disponible dans le flux source apparaît dans l'UI/CLI **avant** le premier événement MCP, sans attendre la fin de tour.
|
|
- Aucun `ReplyChunk::Progress` légitime n'est perdu entre émission backend, transport et affichage.
|
|
- La limite provider est traitée honnêtement : si un provider n'émet rien avant le premier MCP, l'UI n'invente pas de faux message.
|
|
- Les preuves QA permettent de distinguer clairement un manque d'émission backend d'un simple problème de rendu frontend.
|