---
issueRef: "#117"
version: 13
updatedBy: {"kind":"user"}
updatedAt: 1788789622644
---
2026-08-21 Main
- Ticket rouvert pour livraison effective sur la branche backend dédiée `feature/117-ask-agent-sync-background-tasks` depuis `develop` @ `c1d7f6d`.
- Direction produit validée utilisateur: `idea_run_in_background` doit rester disponible pendant un `idea_ask_agent`, mais le moteur doit gérer ça en interne sans dépendre d'un texte/outil spécial des agents.
- Clarification technique établie: aujourd'hui, le rendez-vous `idea_ask_agent` se résout sur le premier `Final` structured, même si des child background tasks liées au rendez-vous restent `Running`; la completion ultérieure réveille le propriétaire pour un nouveau tour, sans second `Final` corrélé au même appelant.
- Architect a figé la cible: une background task lancée pendant un rendez-vous devient une child jointe au rendez-vous. Le premier `Final` devient un `pending_final` candidat si des children jointes restent ouvertes; l'appelant n'est libéré qu'après `pending_final` + toutes children jointes terminales avec succès.
- Architect: les completions de children jointes ne doivent pas suivre le wake asynchrone standard tant que le parent rendez-vous reste ouvert; elles doivent d'abord réévaluer/finaliser le parent. Échec/cancel/timeout d'une child jointe => échec/cancel/timeout parent cohérent, pas succès.
- Points de code ciblés par Architect: `crates/application/src/orchestrator/service.rs` (`run_in_background`, `ask_structured`, complétion rendez-vous, registre active_rendezvous`), modèle/store de `BackgroundTask` pour persister l'état joint/pending_final, chemin completion sink / wake, watchdog rendez-vous, tests `orchestrator_service` + reboot/reconcile.
- Git: branche `feature/117-ask-agent-sync-background-tasks` créée depuis `develop` @ `c1d7f6d`.
- DevBackend a livré un premier patch: le parent rendez-vous attend désormais les children jointes et supprime le wake async standard pour une child jointe tant que le parent rendez-vous est encore ouvert.
- DevBackend a exécuté: `cargo fmt`; `cargo test -p application --test orchestrator_service`; `cargo test -p backend --lib background_tasks_b7_tests::app_reconcile_`; `cargo check -p application -p backend` => verts selon son rapport.
- Écart déclaré par DevBackend: pas de persistance/reconstruction explicite du `pending_final` à travers reboot.
- QA indépendant: chemin chaud VERT (`ask_structured_pending_final_waits_for_joined_background_success`, `ask_structured_joined_background_failure_fails_parent_rendezvous`, suppression du wake async parasite au reconcile boot) mais verdict global ROUGE pour #117 tel qu'écrit.
- Preuves QA: `cargo test -p application ask_structured_pending_final_waits_for_joined_background_success -- --nocapture` => OK; `cargo test -p application joined_background -- --nocapture` => 2/2 OK; `cargo test -p backend app_reconcile_suppresses_joined_child_wake_while_rendezvous_parent_open -- --nocapture` => OK.
- Blocage QA: aucun test ni mécanisme démontré pour reconstruire le `pending_final` après reboot, alors que le ticket #117 exige explicitement que la réponse finale revienne encore à `A` après redémarrage.
- Architect a confirmé: ce gap reboot est un blocker pour clôturer #117; au mieux c'est un lot partiel avec dette séparée, pas une clôture.
- Action: retour DevBackend demandé sur la persistance/reconstruction du `pending_final` et la validation reboot/reconcile complète.