IdeA/.ideai/tickets/117/carnet.md

issueRef, version, updatedBy, updatedAt

issueRef	version	updatedBy	updatedAt
#117	13	kind user	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 BackgroundTaskpour persister l'état joint/pending_final, chemin completion sink / wake, watchdog rendez-vous, testsorchestrator_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.