Consigne donnée au modèle pour la commande Run Insights Requested : récupérer les demandes d'enquête en attente (saisies par l'utilisateur sur l'écran Corrélations manuelles), les traiter, et renvoyer les réponses à l'écran.
L'écran Corrélations manuelles distingue deux situations selon que la combinaison demandée a déjà été calculée par le pipeline ou non.
Sélection en cascade à trois niveaux : « Déclencheur(s) potentiel(s) — catégorie » (les 8 catégories) → « — KPI » (vide par défaut ; sélectionner une ou plusieurs catégories affiche leurs KPI ; lien « afficher tous ») → « — Valeurs » (même mécanique : les valeurs/états encodés des KPI sélectionnés). Les niveaux catégorie et KPI servent de navigation : seuls les éléments du niveau le plus fin sélectionné deviennent les déclencheurs de l'analyse.
Plage temporelle optionnelle : par défaut, l'analyse porte sur tout l'historique de données, en respectant les fenêtres déclarées de chaque facteur (User Beliefs).
« Hypothèse ou question libre » = OU vis-à-vis de la sélection structurée (séparateur « — OU — » affiché à l'écran) : soit une sélection de déclencheurs (cas n°1 si déjà calculée, sinon cas n°2), soit une question libre qui remplace la sélection (toujours cas n°2, traitée au prochain Run).
Base de données de l'analyse : les corrélations manuelles interrogent la totalité de l'historique — les paires du Run sont des Pearson sur tous les jours (le profilage J−3 avant Bad Day ne sert qu'à l'éligibilité des facteurs), et une combinaison absente est calculée sur tout l'historique au prochain Run.
Confirmation & demandes : au clic sur « Demander l'analyse » (cas n°2), une notification verte confirme « Demande enregistrée ! » (composant commun .notif : croix de fermeture, disparaît en quittant l'écran). Chaque demande de la liste « Tes demandes » s'affiche [ déclencheurs ] → effet ? et porte une corbeille de suppression (action API delrequest).
Normalisation des identifiants : les ids longs de l'app (meta.badDay, symptoms.tired…) sont traduits vers les ids courts du moteur (badDay, tired…) pour la recherche dans correlations_<id>.json, et l'app trace les séries des états encodés courts (didi, lateMeal, noAct2…) pour les calques du cas n°1.
Aucun Run nécessaire : l'onglet lit la base correlations_<id>.json et présente immédiatement le détail de l'analyse existante :
1. Le détail des calculs effectués, et le résultat selon Pearson (r, n).
2. Un graphique unique en calques interactifs (refonte 09/07 — le nuage de points a été fusionné dans ce graphique) : toutes les données de chaque facteur de la combinaison sur un même tableau — un calque par facteur, semi-transparent, couleur dédiée ; axes explicites (abscisse = les jours avec graduations, ordonnée non/0 → oui/max) ; la légende est cliquable : désélectionner un facteur masque son calque, recliquer le réaffiche.
3. Un executive summary avec le rappel des conditions — sur le modèle : « Étudié sur la période totale de X jours ; corrélations observées sur 3 jours max à chaque fois ; X Bad Days sur la période. La combinaison de tous ces facteurs dans les 0–3 jours avant un Bad Day arrive X fois sur Y Bad Days — on estime donc qu'il y a une forte corrélation statistique. »
À l'écran : l'onglet affiche que les informations sont indisponibles et viennent d'être demandées — aucune réponse immédiate.
Consignation : la demande est enregistrée dans une base dédiée, le fichier requests_<id>.json — { id, combination (facteurs demandés), requestedAt, status: "pending" | "answered" } — séparée du store des entrées et de la base de corrélations.
Exécution : la recherche est lancée au prochain Run IA depuis la plateforme Claude desktop (Run Insights Requested lit les demandes pending). Le résultat est écrit dans la base de corrélations, la demande passe answered, et l'écran affiche alors le détail complet du cas n°1 (calques, nuage, calculs, executive summary) au prochain chargement — sans action manuelle. La demande entre aussi au carnet d'hypothèses (posée par l'utilisateur → testée).