To-do

Retard 56j · 29.05 +proactif

  - 3 workflows modifiés le 2026-05-22 pour formater SessionDate du webhook Zoho Forms en 3 juin 2026 (Luxon locale fr, toFormat('d MMMM yyyy'))
  - Workflows à valider :
    - vmgE2exd30yVsIvN : New Form Received (Inscription Fide, Fr), input YYYYMMDD, commit e2f142c
    - dadrKh6ARFwRB6h1 : New Form Received (Inscription Fide, En), input YYYYMMDD, commit e2f142c
    - eqbpiZOexnZfwqDH : New Form Received (Préinscription MOS, Fr), input dd/MM/yyyy, commit ac5cb72
  - Méthode : ouvrir un Contact ayant soumis le formulaire après le 2026-05-22 dans Zoho CRM Proactif, related list Notes, note titre Formulaire reçu (…) : le champ Date: doit afficher 3 juin 2026 (et non plus 20260603 ou 25.06.2026)
  - Si aucune soumission organique d'ici l'échéance, faire un test manuel via Zoho Forms

Retard 55j · 30.05 +proactif @zoho-helper

  - Brainstorming entamé le 2026-05-26, pausé en attendant 2 inputs Proactif sur le format des champs et les lookups destinataires. Repos concernés : n8n (workflow Outlook + populate + PDF), zoho-helper (workflow rule + Custom Function Deluge + champs CRM + Zoho Forms config), pdfmonkey (template HTML/CSS de l'attestation).
  - Décisions déjà prises (à conserver) :
    1. Trigger : workflow rule Zoho time-based sur Inscriptions, Date_fin_cours - 14 jours (champ miroir déjà sync via syncDatesCoursVersInscription). 1 inscription = 1 attestation = 1 email formateur.
    2. Scope : uniquement les inscriptions où Cat_gorie_de_formation == "ASO+" (orthographe exacte avec le +, gotcha picklist Zoho documenté dans zoho-helper/.claude/rules/deluge.md gotcha #11). Idéalement aussi filter sur Statut_d_inscription not in [Annulé, Refusé].
    3. Stockage des réponses du formulaire : étendre le module Attestations existant (Zoho CRM Proactif, module id 790258000008720043) avec 5 nouveaux champs : Niveau de début, Niveau final atteint, Objectifs de la mesure atteints (picklist Oui/Non/Partiellement), Remarque (multi-line), Recommandation (multi-line). 1 record Attestation par inscription, lié via lookup Inscription.
    4. Estimation Thomas/Proactif déjà partagée : règle workflow (0.25h Proactif) + modèle email (0.25h Proactif) + Zoho Forms sync CRM (0.5h Thomas) + template PDFMonkey (1.5h Thomas) + automations n8n (1.5h Thomas).
  - Décisions TBD (à clarifier avec Proactif avant d'écrire le spec) :
    1. Format des 2 champs Niveau : picklist (Débutant/Intermédiaire/Avancé, A1-C2, ou échelle métier propre) ? texte libre multi-ligne ? note numérique 1-10 / 1-6 ? plusieurs sous-niveaux notés (Lecture / Écriture / Oral / Informatique) ? Impacte la création des champs CRM, le Zoho Forms, et le rendu PDF.
    2. Lookups destinataires : (a) le formateur qui reçoit le mail avec lien vers le formulaire : nouveau lookup Formateur sur Inscriptions vers Contacts layout Formateur ? via Séance/Suivis (1ère séance liée) ? via Cours.Formateur ? (b) le responsable de formation qui reçoit le PDF : Products.Owner ? un lookup ou email dédié sur Products (à créer) ?
  - Architecture pressentie (sous réserve clarifications) :
    1. Workflow rule Zoho time-based sur Inscriptions → webhook n8n inscription-aso-fin-mesure-j14 → format mail Outlook avec lien pré-rempli vers Zoho Forms (paramètres URL : inscriptionId, contactId) → envoi au formateur.
    2. Formateur remplit Zoho Forms → sync natif Forms→CRM crée le record Attestation avec les 5 champs + lookup Inscription.
    3. Workflow rule Zoho On Create Attestations → webhook n8n attestation-aso-created → fetch Inscription + Contact + Products → POST PDFMonkey template attestation-fin-mesure-aso → upload PDF en pièce jointe sur le record Attestation → email Outlook au responsable de formation (Products.Owner ou champ dédié) avec PDF en attachment.
  - À reprendre via : "On reprend le brainstorming de l'attestation de fin de mesure ASO+ ?" → Claude charge ce TODO + relit n8n/clients/proactif/CLAUDE.md + zoho-helper/clients/proactif/CLAUDE.md + pdfmonkey/.claude/CLAUDE.md, pose les questions TBD restantes, puis écrit le spec + plan.

Retard 55j · 30.05 +proactif

  - Mise en place le 2026-05-23 : 2 workflow rules sur Contacts qui appellent la Custom Function setNationaliteISOContact (dérive Nationalit_ISO depuis Nationalite via Map Dependency API en 2 étapes list + specific). Rule A : On Create avec sources API + Web + Email + Import cochées. Rule B : On Edit avec critère "Nationalite is modified"
  - Backfill des 189 records historiques OK le 2026-05-23 (DONE: updated=189 skippedNoMapping=0 errors=0). Reste à valider que la rule fire effectivement sur les nouvelles créations qui tombent via n8n/API
  - Méthode de validation : laisser tomber ~1 semaine de records puis lancer COQL select id, Nationalite, Nationalit_ISO from Contacts where Created_Time > '2026-05-23T00:00:00+02:00' and Nationalite is not null and Nationalit_ISO is null → devrait renvoyer 0 row
  - Si rows trouvées : checker Setup > Functions > setNationaliteISOContact > View Log Details pour voir si la function a tourné. Causes probables : source API pas cochée dans la rule Create, merge tag ${Contacts.Id} mal saisi en argument, ou scope ZohoCRM.settings.READ perdu sur connection zohoall
  - Fonctions concernées : zoho-helper/clients/proactif/functions/crm/Automation/setNationaliteISOContact.dg + Standalone/backfillNationaliteISOContacts.dg
  - Une fois validé, supprimer aussi la fonction debug debugMapDependencyContacts côté Zoho et le .dg côté repo (déjà proposé en chat le 2026-05-23)

Retard 52j · 02.06 +lm @lm-security

  - Routine remote /schedule trig_015DPU4iWcgjYiX8rUXiKKBJ, cron 37 5 * * 2 (mardi 05h37 UTC = 07h37 Zurich), reprogrammée au mardi exprès pour valider demain (à remettre au lundi si OK). Elle clone lm-security + lm-hub, modèle sonnet, et lance node bin/run-audit.js --deliver.
  - Vérifier SANS l'UI claude.ai (le deep-link routines/ID ne résout pas ; passer par la page liste claude.ai/code/routines). Signaux concrets : commits sur lm-stack/lm-security (reports/<date>.md + state.json, message "chore: audit securite") et sur lm-stack/lm-hub (data/todo.md, "todo: findings securite"), plus l'email à hello@ via le worker lm-security-notify. Check rapide : gh api 'repos/lm-stack/lm-security/commits?per_page=5' --jq '.[].commit.message'
  - Si aucun commit ni email : le run a buté, cause probable n°1 = gh non authentifié dans le sandbox /schedule (le prompt de la routine doit le diagnostiquer). Fix : (a) ajouter un PAT GitHub fine-grained au prompt de la routine (Contents read sur lm-stack + yb-concept, read/write sur lm-security + lm-hub ; un PAT lm-hub existe déjà en secret Pages), ou (b) basculer sur GitHub Actions (logs visibles + secrets natifs, recommandé vu l'opacité de /schedule).
  - Contexte build (session 2026-06-01) : moteur lm-security Node/TDD 45 tests (revue opus, bug dédup gitleaks full-history corrigé), poussé sur lm-stack/lm-security. Worker email prouvé (https://lm-security-notify.hello-cb2.workers.dev, secret dans le password manager et dans le prompt routine). Flag --deliver câblé. Spec et plan : lm-security/docs/superpowers/.
  - Une fois validé : figer le jour définitif (lundi vs mardi), renommer la routine (encore "(lundi)"), et trancher /schedule vs GitHub Actions pour l'observabilité.
  - Vérifié le 2026-06-11 : le run du mardi 2026-06-09 a bien tourné (commit lm-security 05:47 UTC) mais en mode dégradé : 2 repos scannés sur 26+ (gh non authentifié dans le sandbox, cause n°1 anticipée), osv-scanner bloqué (osv.dev inaccessible), email non envoyé (worker lm-security-notify en HTTP 403, confirmé côté Gmail). 0 finding sur les 2 repos scannés (gitleaks + semgrep OK). Décision restante : PAT GitHub dans le prompt de la routine ou bascule GitHub Actions (recommandée par le rapport lui-même), puis figer le jour et renommer la routine.
  - 2026-07-13 : bascule GitHub Actions faite (workflow audit.yml sur lm-security, cron lundi 05h37 UTC, dry-run de validation via input limit, échec de run notifié par email). Reste : poser les secrets AUDIT_GH_PAT (PAT classique scope repo + admin:repo_hook lecture) et LM_SECURITY_EMAIL_SECRET sur le repo lm-security, lancer Run workflow avec limit=3 pour valider, puis run complet et suppression de la routine /schedule trig_015DPU4iWcgjYiX8rUXiKKBJ

Retard 49j · 05.06 +proactif @zoho-helper

  - Objectif : à la création ou duplication d'un cours (Products), réhydrater les picklists enfants de dépendance vidés par le clone Zoho (Remplissage + les 7 autres enfants de Type). Cause : une Map Dependency Zoho n'est qu'un filtre UI (cf .claude/rules/deluge.md gotcha #8).
  - Code déjà écrit et poussé : clients/proactif/functions/crm/Automation/setDependentPicklistDefaultsCours.dg (commit 1888e55, branche main). Spec : docs/specs/2026-06-04-remplissage-defauts-dependance-cours-design.md. Plan détaillé pas-à-pas : docs/plans/2026-06-04-remplissage-defauts-dependance-cours.md.
  - Étapes Zoho (UI manuel) : (1) créer la Custom Function Automation setDependentPicklistDefaultsCours (argument coursId de type Int), coller le code sans les lignes d'en-tête ; (2) linker la connection zohoall (gotcha #9, scope ZohoCRM.settings.READ) ; (3) Test Run sur un cours Type=Fide avec Remplissage vidé, attendu maj vers {"Remplissage":"Oui"} ; (4) créer la rule "All, Cours, Créé" (Products, On Create, sources API+Web+Email+Import, action = la fonction, coursId = ${Products.Id}).
  - Validation E2E : cloner un cours Fide et vérifier que Remplissage et les autres enfants reviennent remplis, plus idempotence (une valeur saisie à la main n'est pas réécrite).
  - Arbitrage ouvert (cf spec) : updateRecord en trigger vide, donc aucune automation aval ne se déclenche sur les champs posés ; si une rule doit fire sur Statut à la création, exclure Statut de l'update silencieux.
  - Réparer le cours Test Fide déjà dupliqué : à la main, ou standalone de backfill (modèle backfillNationaliteISOContacts) si plusieurs cours sont impactés.

Retard 46j · 08.06 +execed @n8n

  - Workflow n8n hdLG3GYGHPYCaFbk (Zoho Affaires, Button: Générer offre) actif sur auto.executiveeducation.app : reçoit un dealId, assemble le payload depuis le CRM (Affaire + Organisation + Contact + Formateurs), génère le PDF via le subflow PDFMonkey MjlDoaqpQdwjn1f8 et l'attache à l'Affaire
  - Fait le 2026-06-08 (commit df4ba68) : fix des bios formateurs, le nœud Get Formateurs passe de POST /coql à GET /Contacts?ids=...&fields=... car le credential OAuth Zoho n'a pas le scope COQL. Validé via test MCP sur l'Affaire GILAI (40556000108109026)
  - Reste à valider le rendu PDF complet sur une Affaire de test bien remplie
  - Corriger côté CRM avant validation finale : objectifs Objectif_1/2/3 avec espaces manquants à la saisie (ex GILAI « Renforcerlagouvernancedesdonnées... »), subform Programme à remplir (Titre, Durée, Unité, Objectifs) sinon programme vide dans le PDF, organisations sans adresse (Rue, Code_postal, Ville) donc destinataire incomplet
  - Vérifier ou câbler le bouton « Générer offre » sur le module Affaires (déclencheur prod : POST du dealId vers le webhook zoho-affaires-button-offre, Basic Auth)
  - Flag availableInMCP strippé par la CI sync-to-n8n.yml à chaque déploiement : à réactiver à la main pour tester via MCP, ou à ajouter à la whitelist settings de la CI pour le rendre durable
  - Réfs : plan docs/superpowers/plans/2026-06-05-generation-offre-pdfmonkey.md et spec docs/superpowers/specs/2026-06-05-generation-offre-pdfmonkey-design.md

Retard 45j · 09.06 +proactif @n8n

  - Volet Séances ASO+ validé en réel le 2026-07-15 via la fenêtre glissante (appels bulk CRM/Creator sur 3 cours, ~250 séances/cours, aucune erreur de concurrence, réconciliation vérifiée). Restent les Suivis (créer une inscription de test) et les Séances PAP (couplé au retest PAP du 2026-06-12)
  - PR #22 (Phase 1 Suivis, workflow uYtGU1PoP1bQ59h50GQUH) et PR #23 (Phase 2 Séances ASO+/PAP, VRK7hkby805TzQAx + sai4IbspbIqnEReX) déployées en prod le 2026-06-09 : fan-out 1 appel par séance remplacé par des appels bulk (CRM 100 par appel, Creator 200 par appel) pour corriger la limite de concurrence Zoho ("maximum API calls simultaneously", erreur item 33)
  - Test : créer un cours ASO+, un cours PAP et une inscription de test ; dans le log d'exécution n8n, vérifier des appels bulk (2 ou 3) au lieu de la rafale (plus d'erreur item 33)
  - Vérifier Suivis et Séances présents en CRM ET Creator, avec ID_Zoho_Creator réconcilié des deux côtés, dates Creator au format dd-MMM-yyyy, et PATCH Date_de_fin du cours PAP correct
  - Non-régression : inscription Test Fide (1 séance via l'ancien chemin Create Seance), cours MOS et KIM (WordPress) inchangés
  - Phase 2 non vérifiable via MCP (subflows availableInMCP false) : l'E2E est la seule validation comportementale. Réf : docs/superpowers/specs/2026-06-09-suivis-seances-bulk-anti-ratelimit-design.md et docs/superpowers/plans/2026-06-09-suivis-seances-bulk.md
  - Incident test 2026-07-15 14:57 : inscription ASO+ créée sans dates de mesure, ~250 suivis générés jusqu'à fin juillet 2027 (fallback 1900-2099 du Search Séances mesure dans Inscription créée). Fix déployé (n8n 96f023ad, CI verte) : IF Mesure renseignée ? court-circuite vers un NoOp si mesure vide (les suivis viennent du placement aso-inscription-placee), fallbacks retirés du criteria. Au passage le bulk Suivis anti rate-limit est de fait exercé (250 suivis en bulk sans erreur de concurrence) : reste l'E2E fonctionnel via la transition blueprint, APRÈS purge des ~250 suivis de test (one-shot n8n à monter, suivis CRM + miroirs Creator)
  - Rectif 2026-07-15 (décision Thomas) : abandon du garde-fou Mesure renseignée ? au profit d'une coupure franche. Inscription créée ne génère plus AUCUN suivi pour ASO/ASO+ (sortie true de Est un cours ASO ? vers NoOp terminal) ; les suivis ASO viennent exclusivement du dispatch (Inscription ASO+ placée pzuBGj2uVD34Nt4e). 4 nœuds ASO retirés + bloc bornage nettoyé du code partagé Prepare Suivi rows, autres types inchangés (n8n 94fa0a20). E2E fonctionnel du dispatch encore à faire, APRÈS purge des ~250 suivis de test

Retard 43j · 11.06 +proactif @mafondue

  - Go du re-scrape de tout le canton de Vaud acté : meeting du 2026-06-03 (PoC partiel 409 leads validé, emails passés chez NeverBounce et triés par Fabien), confirmé par Thomas le 2026-06-11. ~2'900 leads VD attendus au complet (vs 409 sur 14 % du périmètre)
  - Préalable bloquant (Thomas, billing) : upgrader le compte Apify en Starter ($29/mois, ~2 mois), le tier FREE cape à $5 et avait coupé 410 searches sur 476 le 2026-05-22
  - Puis relancer compass/crawler-google-places avec mafondue/data-enrichment/poc-vaud/apify_vaud_input.json (476 searches, input prêt, scrapeContacts: true), rejouer le pipeline (dédup placeId, buckets cœur/secondaire/hors-cible, régénérer leads-vaud.xlsx), et repasser les nouveaux emails chez NeverBounce avant toute campagne
  - Suspens connexes du fil email du 2026-06-04 : répondre à Fabien sur les offres Fondue (rester sur les poids différents ou détailler chaque fondue), relancer pour l'accès n8n principal (compte créé par Fabien, invitation reçue) et pour les infos offres Fondue + Événement promises
  - Contexte cible : campagnes email prévues en août, limite Zoho 1'000 emails/jour à étaler sur un planning
  - Réfs : mafondue/data-enrichment/STATUS.md et mafondue/.claude/CLAUDE.md (mis à jour le 2026-06-11), bilan PoC poc-vaud/bilan-poc-vaud.md

Retard 42j · 12.06 +proactif @n8n

  - Volet ASO soldé le 2026-07-15 : la fenêtre glissante a généré ~250 séances par cours sur 3 cours en réel (plusieurs chunks par cours, CRM + Creator réconciliés), après conversion des 7 références $().item fragiles restantes de VRK7hkby805TzQAx en .first() (commit 7d6bceea). Reste le volet PAP ci-dessous
  - Fix déployé le 2026-06-11 (commit dd981a3 sur lm-stack/n8n) : .item remplacé par .first() dans le node Build Séance Creator chunks des deux générateurs (PAP sai4IbspbIqnEReX, ASO VRK7hkby805TzQAx). L'erreur paired item ne survenait qu'au-delà de 100 séances (2 chunks et plus), invisible sur les tests à chunk unique
  - Avant le retest : supprimer le cours PAP de test planté du 2026-06-11 (la fonction Deluge purgeSeancesSuivisCoursSupprime nettoie les 120 séances CRM orphelines créées avant le crash), puis recréer un cours PAP
  - Vérifier la chaîne bulk complète : 120 séances CRM, séances Creator, ID_Zoho_Creator côté CRM et ID_Zoho_CRM côté Creator réconciliés, PATCH Date_de_fin du cours
  - Si possible tester aussi un cours ASO+ de plus de 50 jours ouvrés (plus de 100 séances, même bug latent corrigé)
  - Complète la tâche E2E bulk du 2026-06-09 (génération bulk Suivis et Séances anti rate-limit)

Retard 42j · 12.06 +execed @execed

  - Pourquoi : suite à la décommission du workflow GitHub Actions sync-changelog.yml du repo execed (qui publiait un changelog vers le WordPress Knowledge, supprimé de master et develop le 2026-06-04). Ce workflow appelait l'API Anthropic pour générer les résumés. Le secret GitHub ANTHROPIC_API_KEY a été supprimé du repo, mais la valeur de la clé reste active à la source.
  - Action : se connecter à la console Anthropic avec le compte ExecEd hec.execed@unil.ch, repérer la clé qui servait au workflow changelog, puis la révoquer / supprimer.
  - Voir aussi (cleanup parallèle, hors scope de cette tâche) : le WordPress Application Password (ex-secret WP_APP_PASSWORD) reste lui aussi actif côté WordPress et serait à révoquer dans le profil de l'utilisateur WP.

Retard 42j · 12.06 +proactif @n8n

  - Pourquoi : les séances PAP générées se créent dans le CRM mais échouent à la sync Zoho Creator (workflow i6EO8vIzV0bG2fFn "Séance créée", node Create Seance vers le form Seances_Form) avec erreur 3001 "Invalid column value for Salle". Le champ Salle est obligatoire côté Creator (lookup mandatory), or les séances PAP partent sans salle.
  - Cause : le subflow sai4IbspbIqnEReX (Generate PAP Sessions) code en dur salleId: "", et le node Generate PAP Sessions du parent ijgMMlqpQEz_6-qAR_Z_Y (Cours créé) ne passe pas coursSalle au subflow, contrairement à la branche ASO qui passe coursSalle.
  - Préalable bloquant : demander à Proactif quelle salle attribuer aux séances PAP. Ont-elles une salle fixe, et si oui laquelle (record du module Salles) ? PAP est une mesure d'insertion (DGEM), il se peut qu'il n'y ait pas de salle physique.
  - Fix selon la réponse : (a) si les cours PAP portent une salle, câbler coursSalle comme pour l'ASO (ajouter l'input coursSalle sur le node Generate PAP, au trigger du subflow, et salleId: coursSalle dans Create Séance) ; (b) si pas de salle fixe, définir une salle par défaut à écrire, ou rendre le champ Salle non obligatoire côté Creator (impacte TOUTES les séances, à valider avant).
  - Contexte parent : suite du fix Centre des séances ASO/PAP (commit 06633db sur lm-stack/n8n, seanceCenter prend coursCentre la marque au lieu de coursLocation la ville). ASO confirmé OK après ajout de l'option ASO+ dans la dropdown Categorie du form Creator. Reste aussi à vérifier que la marque Centre des cours PAP est dans la dropdown Creator (pas Groupe Proactif, absent côté Creator).

Retard 36j · 18.06 +proactif @zoho-helper @n8n

  - Décision (brainstorming 2026-06-18) : renouveler un forfait de séances Allemand sans tout re-saisir. Proactif prépare, le client valide via un Zoho Form prérempli, facture directe (pas de re-signature). Nombre de séances + montant figés par Proactif (le client valide, pas de recalcul côté form).
  - Modèle de données : une offre = un Deal de type "Renouvellement" (valeur picklist à ajouter au type de Deal). On réutilise le Cours (Products) existant : on lui ajoute une 2e inscription (le renouvellement) et on étend sa Date_de_fin. 1 cours = N inscriptions (1 par forfait).
  - Préparation = widget Zoho retenu (React/Vite, pattern session-calendar / session-management) : choisir le cours à renouveler, ajuster séances/montant/nouvelle date de fin, générer le Deal "Renouvellement" rattaché au cours via un nouveau lookup Cours_a_renouveler (Deals vers Products). Forme à préciser : Web Tab "Renouvellements" ou widget-bouton sur la fiche Cours/Contact. Garde-fous : 0 cours trouvé = anomalie (ne pas traiter, alerter), plusieurs = le plus récent ; retrouver le cours via la dernière inscription Allemand du contact (pas forcément "active", l'ancien forfait est souvent épuisé au moment du renouvellement). Bouton custom et clone natif envisagés puis écartés au profit du widget.
  - Validation client = nouveau Zoho Form "Renouvellement Allemand" prérempli (contact, cours, séances, montant) ; le client confirme, choisit le moyen de paiement Stripe ou virement (comme le form Inscription actuel WF3), complète adresse/consentement.
  - Soumission = nouveau workflow n8n "New Form Received (Renouvellement, Allemand)" calqué sur 1DQIOdYpa981RdSi (form Inscription) mais SANS créer de cours : marquer le Deal gagné (Offre_signée=Oui, date de succès, moyen de paiement), étendre Date_de_fin du cours, créer la 2e inscription (Contact + Formation = cours existant), créer la facture directe, Stripe si choisi, Task "Planifier les séances" (séances créées à la main comme aujourd'hui).
  - Réutilise l'existant : WF1 k5lJ2nTAccxw3xjL (génération offre PDFMonkey), WF2 oRyd45SUtL48VPpQ (offre gratuite), WF3 1DQIOdYpa981RdSi (inscription vers cours/inscription/facture/Stripe), subflow Create Deal POCzgxlK3jNNhOFi. Offre Allemand = Deal ; flux actuel offre vers form offre gratuite vers form inscription.
  - À confirmer avant la spec : (a) date de fin du cours saisie par Proactif ou calculée depuis le nombre de séances ; (b) séances créées manuellement (Task) ou générées auto ; (c) PDF récap de renouvellement utile ou non ; (d) noms de champs CRM exacts (type de Deal, Products Date_de_fin, Inscriptions, Factures) via le MCP Zoho CRM Proactif. Puis écrire spec + plan (superpowers).
  - Relevé des api_names CRM fait le 2026-07-06 via MCP (question d) : Deals.Type existe (valeurs -None-, Existing Business, New Business, PAS de Renouvellement) mais champ unused hors layout, donc ajouter la valeur ET poser le champ sur le layout ; aucun lookup Deals vers Products, Cours_a_renouveler à créer ; Offre_sign_e (picklist Oui/Non), Date_du_succ_s, Moyen_de_paiement (Stripe/Facture). Products : Date_de_d_but et Date_de_fin (datetime, graphie exacte d_but) ; piège : aucune valeur Allemand dans Products.Type, les cours Allemand se filtrent par Centre = Allemand.ch (actual_value exacte). Inscriptions : Contact, Formation (label Cours), Statut_d_inscription, Cat_gorie_de_formation ; bonus : le lookup Formation_Precedente (Cours précédent) vers Products existe déjà, réutilisable. Factures (module custom, pas Invoices natif) : Participant, Inscription, Affaire, MontantTotal (HT), MontantTotalTTC, StatutFacture, Modele. Restent les questions a, b, c (date de fin saisie ou calculée, séances manuelles ou auto, PDF récap ou non) avant d'écrire la spec

Retard 35j · 19.06 +proactif @zoho-helper

  - Widget déployé et fonctionnel : recherche participant, sélection d'une plage de dates dans un calendrier (jours à séances marqués), application d'un statut à toutes les séances de la plage, bandeau de confirmation persistant avec liens cliquables vers chaque fiche Suivi, en composant Home. Reste uniquement le polish visuel pour le rendre indiscernable de l'UI Zoho CRM. Code : clients/proactif/widgets/crm/suivi-statut/ (React + Vite + Tailwind, build via build.ps1, page d'index /index.html).
  - Déjà fait dans le dernier build : suppression de la carte/conteneur (ni bordure ni ombre), fond transparent, contenu pleine largeur, 2 colonnes (gauche participant + statut + bouton, droite calendrier), texte d'aide du calendrier retiré, police Puvi via CDN Zoho, bouton et champs calqués sur le CSS Zoho fourni (classes .zbtn et .zinput dans src/index.css, avec var(--primaryBackground) etc. et fallback navy ExecEd #0C2340).
  - Fix connu à appliquer en premier : retirer la classe bg-slate-50 du <body> dans index.html, c'est le fond gris résiduel (le background:transparent du CSS est battu par la classe Tailwind, question de spécificité).
  - Questions à poser à l'utilisateur au début, avant de coder : (1) relever dans l'inspecteur, sur un vrai bouton et un vrai input du CRM Proactif, les valeurs calculées de --primaryBackground, --primaryBackgroundHover, --primaryColor, --primaryShadow, --buttonBorderRadius, --formBorder, --lyte-input-border-radius, --baseColor ; sinon donner directement la teinte voulue du bouton (le navy #0C2340 n'est qu'un fallback non validé). (2) vérifier si l'iframe du widget hérite des variables de thème Zoho : tester var(--primaryBackground) SANS fallback et voir si le bouton prend la couleur du thème. (3) confirmer que Puvi se charge bien dans l'iframe (sinon fallback système).
  - À documenter pour les prochains widgets (pièges résolus au déploiement) dans clients/proactif/CLAUDE.md ou .claude/rules/widgets.md : activer le REST API (slider OAuth2) de chaque fonction Standalone sinon NOT_ACTIVE quand le widget l'appelle ; parser crmAPIRequest avec .get("params") et non .toMap() ; page d'index = /index.html (pas /app/index.html) pour un composant Home, sinon 404 sur app/app/index.html ; COQL en lignes courtes (la longue ligne se coupe au copier-coller et casse la string) ; replaceAll en Deluge prend une regex (classe [():] au lieu de remplacer "(" seul).
  - Follow-up session 2026-06-24 (ajout du sélecteur de créneau « Appliquer à ») : restreindre le widget aux seuls contacts ET suivis auxquels l'utilisateur connecté a accès, car il expose actuellement TOUS les contacts et TOUS les suivis à n'importe quel utilisateur. Cause : les Standalone searchParticipants et getParticipantSuivis tournent en permissions élevées (OAuth de la fonction + connexion zohoall pour la COQL), donc elles court-circuitent les règles de partage / ownership / territoire Zoho de l'utilisateur appelant. À faire : identifier l'utilisateur connecté (zoho.loginuserid en Deluge ou ZOHO.CRM.CONFIG.getCurrentUser côté widget) et filtrer contacts + suivis par ownership / partage (clarifier le modèle d'accès Proactif : un formateur ne doit voir que ses participants), vérifier aussi applySuiviStatut côté écriture.
  - Point git du 2026-07-06 : le code (fonctions Deluge corrigées avec parsing .get("params") et COQL searchParticipants, widget réécrit) est déjà committé et poussé sur feat/widget-suivi-statut (branche synchronisée avec origin, working tree propre) ; il ne reste que le merge de feat/widget-suivi-statut dans main

Retard 32j · 22.06

  - Site déployé le 2026-05-08 comme proposition gratuite à Eric, patron d'Alpha-Contrôle SA (Ursy, FR), voir mail draft Gmail « Une proposition de site web, sans engagement »
  - URL : https://alpha-controle.pages.dev/, projet alpha-controle sur le compte CF Pages de hello@lausanne.marketing
  - Repo : https://github.com/lm-stack/alpha (commit 6cb4960 du 2026-05-08)
  - Le 2026-06-22 : si pas d'engagement client, DELETE /accounts/{account_id}/pages/projects/alpha-controle via MCP Cloudflare, et archiver/supprimer le repo GitHub
  - Si Eric a mordu d'ici là : retirer cette tâche, le site devient un projet client (et remplacer assets/inspiration-morand.png par une vraie photo de l'atelier d'Ursy)
  - Constat du 2026-07-06 : échéance dépassée de deux semaines, aucune décision enregistrée ; vérifier si Eric a répondu puis trancher : suppression (désormais via wrangler avec cf-lm, le MCP Cloudflare est déprécié) + archivage du repo, ou conversion en projet client ; suppression exécutable par Claude sur feu vert

Retard 31j · 23.06 +proactif @n8n

  - Le domaine intuify.ch a été migré de Hostinger vers Infomaniak. Le credential SMTP auto@intuify.ch a été repointé vers mail.infomaniak.com port 465 SSL (user et mot de passe inchangés), mais le test de connexion n8n échoue le 2026-06-22 (erreur « Couldn't connect with these settings »), probablement propagation. Re-tester le 2026-06-23 ; si toujours KO, vérifier le couple port/SSL (465 + SSL ON, ou 587 + STARTTLS) et que la boîte Infomaniak est active.
  - MaFondue : les 4 workflows du backup sont déjà construits et vérifiés (run de backup OK le 2026-06-22, seul l'email échoue faute de SMTP). Une fois le credential SMTP fonctionnel sur MaFondue (à créer avec les mêmes réglages) : prévenir Claude qui l'assignera aux 2 nodes Send Email (workflows icBHrZ0GfJ0bTdiu et tO1RIzGpTitTYm2o via le MCP), réglera Error Workflow en UI sur les 3 workflows, activera le schedule 03h17 et relancera le backup test.
  - Proactif : le credential SMTP fEkxl274OhhoQpMJ (SMTP account auto@intuify.ch) a été repointé vers Infomaniak ; le re-tester. Il sert à 6 workflows dont l'error workflow ZOQ7ifWOLtJvlCcl, donc tant qu'il ne passe pas, les notifications d'erreur Proactif ne partent plus.
  - Remplace l'item de build 2026-06-17 (les 4 workflows MaFondue sont faits et vérifiés ; ne reste que ce volet SMTP).

Retard 31j · 23.06 +lm @zoho-helper

  - Le code Deluge est déjà corrigé (bascule sur connection:"pdfmonkey", commits zoho-helper ae7548f + c69e9dd du 2026-06-11), mais les anciennes clés ExecEd et Proactif restent dans l'historique git : seule la rotation neutralise la fuite, pas le retrait du fichier.
  - À faire : régénérer les deux clés dans le dashboard PDFMonkey, puis reporter les nouvelles valeurs dans les deux Zoho Connections nommées pdfmonkey (CRM ExecEd + CRM Proactif). L'utilisateur pose les secrets lui-même, jamais en clair dans le chat.
  - Référence : lm-security/SECURITY-SCAN-REPORT.md (finding #1 ; déplacé de la racine du workspace le 2026-07-09).
  - Consolide les anciennes tâches sécurité du 2026-06-12 et du 2026-06-18 : le Bearer OTP LM est suivi à part (tâche dédiée du 2026-06-19), le Bearer Proactif AI et DataForSEO sont déjà résolus.

Retard 31j · 23.06 +lubishtani @lubishtani

  - Reprise prévue la semaine prochaine du chantier landing pages (référencement local de l'Étude par lieux et par domaines de droit)
  - Déjà fait cette semaine : modèle réutilisable + page exemple avocat-penal.html (séquence SEO constante, données structurées JSON-LD LegalService/Attorney + FAQPage + BreadcrumbList), doc de stratégie docs/landing-pages-seo.md (réponse au risque Google doorway/contenu dupliqué, verdict par type de page), passe design (logo SVG, H1 compact, fil d'Ariane doré, portrait avec équerres, sections allégées). En ligne sur https://lubi.lausanne.marketing/avocat-penal
  - À faire : figer la liste finale des pages (lieux avocat-lausanne, avocat-morges, avocat-fribourg ; domaines avocat-penal, avocat-etranger, avocat-immigration, avocat-assurance ; niches avocat-terrorisme, avocat-covid19, avocat-renteAI ; page albanaise avokat-shqiptar), décliner le gabarit avec un contenu unique par page (règle une intention = une page, fusionner penal et penaliste), ajouter un hub Domaines/Régions + maillage nav/footer/sitemap, placer la 2e image
  - Avant mise en ligne en prod : basculer le canonical sur le domaine de production réel (la prod reste etude-lubishtani.ch sous WordPress) et brancher le formulaire de contact (Worker + Email Routing)
  - Session 2026-06-22 : gros travail design sur la page exemple avocat-penal.html, à reverser dans le gabarit avant de décliner les autres pages. Hero repris comme l'accueil en 2 colonnes avec slider photo de Me Lubishtani (3 clichés en fondu automatique) et H1 réduit pour les pages autres que l'accueil ; section réponse en texte seul (portrait déplacé dans le hero) ; Quand faire appel en boîtes à icônes (6 cas) ; Notre approche en section Steps (01/02/03) ; Où intervient en 3 colonnes Lausanne/Bienne/Suisse romande avec photos Unsplash (maquette : remplacer par de vraies photos des bureaux, Bienne étant un visuel générique) ; FAQ en 2 colonnes avec photo à gauche et 6 questions ; sections Pourquoi confier et Où intervient inversées (ordre et couleurs de fond) ; bloc contact = formulaire seul + 5 coordonnées en colonne à droite (Google Maps retiré), footer revu. Tout déployé en continu sur lubi.lausanne.marketing/avocat-penal (deploy manuel wrangler ; le formulaire reste action=# sans backend). On reprend demain.

Retard 31j · 23.06 +proactif @zoho-helper

  - Le subflow n8n 3BZcBFfWQvsNkC3b (Upload document Proactif) a été migré le 2026-06-18 vers un upload binaire + POST /crm/v8/{module}/{id}/Attachments en OAuth2 (credential Zoho account), commit n8n 1afdff3 : il n'appelle plus cette fonction Deluge.
  - Sécurité : la zapikey de la fonction était en clair dans l'URL du workflow et reste dans l'historique git. Révoquer/régénérer côté Zoho (supprimer le fichier ne suffit pas). Ce secret n'était pas listé dans SECURITY-SCAN-REPORT.md.
  - Pendant du TODO execed du 2026-06-23 (même chantier upload sans fonction Deluge). La migration n8n Proactif est faite ; reste la suppression de la fonction et la rotation du secret.
  - Vérification pré-suppression du 2026-07-06 : aucune référence runtime restante. Repo n8n : zéro occurrence (subflow 3BZcBFfWQvsNkC3b bien migré, aucun workflow versionné ne contient zapikey). Zoho Proactif via MCP : 58/58 workflow rules inspectées (16 avec actions functions, aucune pdfmonkey), 32/32 webhooks (tous vers auto.proactif.ch), 2 boutons custom sans lien. zoho-helper : seule sa définition .dg + doc. Limites : schedules/blueprints non exposés par le MCP, fonctions Zoho non versionnées invisibles. Feu vert : supprimer la fonction puis révoquer la zapikey

Retard 31j · 23.06 +execed @zoho-helper

  - Upload de documents execed (subflow n8n upload-document, ID 7rCIM0fiAO26EHs4) migré le 2026-06-16 vers un pattern sans fonction Deluge : download du PDF en binaire puis POST /crm/v8/{module}/{id}/Attachments en OAuth2 (credential Zoho account), modèle Proactif mXQm0J4CBDv4XV1p. Source pdfmonkey validée (GILAI) ; source odoo (facture portail) à valider via une facture de test.
  - Après ~1 semaine de stabilité : supprimer la fonction Deluge uploadDocument (zoho-helper/clients/execed/functions/crm/Standalone/uploadDocument.dg) cote Zoho execed, APRES avoir confirmé qu'aucun autre déclencheur Zoho ne l'appelle. Supprimer aussi le credential n8n devenu inutile zapikey (Upload document).
  - Si le pattern tient : migrer les autres clients n8n sur le même modèle (download binaire + Attachments OAuth2), en priorité Proactif dont le subflow 3BZcBFfWQvsNkC3b appelle encore la fonction Deluge getrequireddatafrompdfmonkey avec une zapikey en clair dans l'URL (faille de sécurité à régler par la même occasion).
  - Le reste de la chaîne offre execed est terminé : transmission payload (JSON.stringify dans MjlDoaqpQdwjn1f8), images réhébergées sur execed-tools.pages.dev/offre, fond default-page en CSS, champs CRM Délai de réalisation / Domaine personnalisé + câblage, upload OAuth.
  - Vérification pré-suppression du 2026-07-06 : aucune référence runtime restante. Zoho ExecEd via MCP : 84/84 workflow rules inspectées (20 avec actions functions, aucune uploadDocument), 50/50 webhooks sans URL de fonction ni zapikey. Le credential n8n zapikey (Upload document) est orphelin dans les workflows versionnés. Trace inerte à nettoyer en même temps : le node template n8n/nodes/zoho/upload-document.json (bibliothèque de snippets, zapikey via variable d'env) à supprimer ou migrer vers le pattern Attachments OAuth2. Volet Proactif déjà couvert (subflow 3BZcBFfWQvsNkC3b migré le 2026-06-18)

Retard 25j · 29.06 +proactif @mafondue

  - Build du 2026-06-22 fait via le MCP Zoho MaFondue (org Froval SA, édition Professional) : 4 modules configurés (Prospects, Comptes ex-Entreprises, Contacts, Offres ex-Affaires), champs ERD créés, champs hors-ERD masqués (non destructif). Détail complet dans mafondue/crm-zoho/STATUS.md, section "Build 2026-06-22".
  - Décision bloquée par Fabien : mail envoyé le 2026-06-22 sur la suppression des ~12 462 contacts (dernière modif 2022) et ~1 449 prospects (2024) existants, de qualité douteuse. S'il valide la suppression, repartir sur une base propre et aligner strictement sur l'ERD (supprimer les champs legacy, listes en strict ERD).
  - Trancher "Origine du prospect" sur Contacts : merge (garder les valeurs maison Fabien, Connaissance, Réseaux sociaux (IG, FB), Newsletter, Salon - Evénement, plus les valeurs ERD) ou strict ERD (10 valeurs, le reste en inactif). Si Fabien fait supprimer les données : strict ERD. Prospects est déjà en strict ERD.
  - Champs legacy Bexio (Adresse, Localité, Langue, Bexio_Client_ID, Gestion du consentement, etc.) actuellement masqués sur Comptes/Contacts/Prospects : les supprimer si Fabien valide la suppression, sinon les laisser masqués.
  - Affichage conditionnel non réalisé (limite d'édition) : les règles de mise en page (Pays si Canton = Étranger, Autorisation si Ambassadeur = Oui, langue préremplie selon le canton) nécessitent Zoho Enterprise ; l'org est en Professional. Décider : passer en Enterprise, laisser les champs toujours visibles, ou poser une règle de validation "Pays obligatoire si Canton = Étranger" (dispo en Professional).
  - Placer le champ Score natif sur la fiche Prospects (présent mais hors layout, géré par les règles de scoring Zia).
  - Limite connue : la section "Google AdWords" et quelques champs système (conversion, désabonnement, enrichissement, dernière activité) ne sont pas masquables via l'API.

Retard 24j · 30.06 +vaumarcus @vaumarcus

  - Adresse actuellement configurée : info@chateauvaumarcus.ch (vars EMAIL_TO et destination_address du binding send_email dans workers/contact-mailer/wrangler.toml)
  - Confirmer avec la cliente l'adresse de réception définitive des demandes de contact du château
  - Procédure : éditer EMAIL_TO et destination_address dans wrangler.toml, vérifier la nouvelle adresse comme destination dans Email Routing (compte LM) si elle change, puis cf-lm puis npx wrangler deploy
  - Tâche issue de la finalisation du formulaire de contact (worker vaumarcus-contact-mailer + Email Routing) le 2026-06-16

Retard 15j · 09.07 +lm @lm

  - Références d'accès DataForSEO (login/password, placeholders inclus) retirées de README-routines.md et INFRA.md le 2026-06-09 lors de l'audit sécurité
  - Pipeline conservé mais inactif côté DataForSEO : scripts/fetch-dataforseo.ts, scripts/analyze-signals.ts, workflow .github/workflows/seo-data-refresh.yml
  - À faire : recréer le compte DataForSEO, regénérer les clés API, les poser en GitHub Secrets DATAFORSEO_LOGIN / DATAFORSEO_PASSWORD du repo lm (jamais en clair), re-documenter, valider un run de bout en bout
  - Objectif : réactiver l'idéation SEO data-driven (volume, difficulté, idées de mots-clés) pour les articles automatisés

Retard 14j · 10.07 +proactif @n8n

  - Diagnostic CONFIRMÉ le 2026-07-10 (test reproduit par API : modification du Compte test à 08:38, règle exécutée, zéro exécution n8n, zéro échec dans le journal webhook Zoho interrogé sur 2 jours) : Zoho n'émet jamais la requête, signature d'une connexion non autorisée. Les Connections ne sont pas exposées par l'API : correction UI uniquement
  - Action Thomas (UI Zoho) : Paramètres, Espace développeur, Connexions, « n8n » : vérifier statut « Connectée » (cliquer Connecter si besoin), type Service personnalisé auth API Key, paramètre de type HEADER nommé exactement Authorization, valeur Basic du gestionnaire (credential « Internal n8n API (MaFondue) »)
  - Re-test après correction : modifier le Compte « Test Sync Intuify » (id 1001507000026835106, n'importe quelle édition) et vérifier qu'une exécution apparaît sur CfRDjBCeqeOLlTuZ (search_executions) ; sans effet de bord, le node « Sync vers Bexio » est désactivé
  - Acquis : credentials « Zoho CRM » (yEyouvdlkTZWYirP, refresh token re-validé le 2026-07-10) et « Internal n8n API (MaFondue) » (iGCOQvLQhQZcbYHY) bindés sur tous les nodes ; publiés : Zoho (Comptes created/edited) CfRDjBCeqeOLlTuZ (webhook en écoute, 401 vérifié) + Subflow: Bexio (Upsert contact) 510xhl625Oa1DhMB ; côté Zoho : webhook n8n : Comptes upsert (1001507000026847001) + rule n8n : Comptes créés/modifiés (1001507000026840003) actifs ; gotcha : pas de scope org sur le self-client (ne pas smoke-tester via /crm/v8/org)
  - Reste de la Phase B : PAT Bexio (developer.bexio.com, token « n8n sync Zoho ») + credential Bearer « Bexio PAT » dans n8n, binding des 8 nodes Bexio + réactivation du node « Sync vers Bexio », résolution des constantes Bexio (user_id via GET /2.0/users, codes kb_item_status_id), publication des workflows restants, règle Contacts + bouton Rafraîchir côté Zoho, tests unitaires, seed initial (valider avec Fabien : historique factures = exercice courant, présence de fournisseurs), activation du Delta scan
  - Réfs : plan lm-stack/n8n docs/superpowers/plans/2026-07-09-sync-bexio-zoho-mafondue.md, mapping clients/mafondue/zoho-sync-fields.md, état détaillé dans clients/mafondue/CLAUDE.md

Retard 14j · 10.07 +proactif @n8n

  - État : chaîne complète EN PROD et validée E2E par Thomas le 2026-07-14 (fiche Attestation Modèle = ASO -> rule CRM -> webhook -> n8n dispatch -> PDF attaché). Template PDFMonkey "ATTESTATION ASO" (id 346f83bb-e26f-4c0c-904e-f591dd3c6ba7), source pdfmonkey/clients/proactif/attestation-aso/
  - Détail complet dans le plan : n8n/docs/superpowers/plans/2026-07-01-attestation-aso.md ; repos concernés : n8n, pdfmonkey, zoho-helper
  - Avancement 2026-07-06 : doc faite (CLAUDE.md n8n + pdfmonkey) ; mapping civilité confirmé contre le picklist réel (gotcha : Non spécifié sortirait brut sur le PDF) ; webhook vérifié actif ; signatures embarquées en base64 dans le template PDFMonkey (pdfmonkey 3f75337, CI verte, plus rien à héberger) ; fonction Deluge renommée genererattestationaso (taxonomie Button, zoho-helper 344ac3e) + restructurée avec return final unique exigé par le validateur (a1fdd1c) ; fonction CRÉÉE dans Zoho par Thomas le 2026-07-06
  - Avancement 2026-07-14 : architecture finale posée (décision Thomas : PAS de bouton, un seul webhook CRM pour ASO et MMT, dispatch sur le Modèle côté n8n). CRM via MCP : webhook « n8n - Attestation créée » (790258000012352001, POST attestation-created, form-data attestationId + modele, auth type connection sur la Connection n8n, zéro secret) + rule « Attestation créée » (790258000012353001, On Create Attestations, criteria Modèle dans [ASO, MMT], active, vérifiée par GET). n8n via repo + CI (run 29323508506 vert) : workflow pWXEk2MI735VWiRR renommé « Attestation créée (Zoho CRM) », webhook re-pointé attestation-created, Switch Modèle (ASO = chaîne PDFMonkey existante, MMT = Forward vers h13NHQJauBZLfhqL). La rule « All, Attestations, Créée » (initPresencesJournalieres) n'a pas été touchée. Fonction Deluge genererattestationaso ORPHELINE (bouton abandonné) : suppression dans Zoho possible, .dg archivé dans zoho-helper. Limite branche MMT : les champs caisse de chômage ne transitent pas (fallback gracieux, champs PDF 1.141/1.65 vides). Doc à jour : n8n/clients/proactif/CLAUDE.md (commits b8e2b522, 752d104a, 25f264ad)
  - Avancement 2026-07-14 (suite) : test E2E validé par Thomas (« ça fonctionne ») ; webhook CRM « n8n - Attestation créée » enrichi à 17 params pour la branche MMT (identité contact, mesure, cours + taux et centre, date_format yyyy-mm-dd, vérifié par GET) et Forward MMT relaie désormais le body complet (n8n 8ff0be61, CI 29330837598 verte) : sans ça le PDF MMT sortait sans identité (Aggregate Data lit le body du webhook, aucun fallback). Reste connu : caisse de chômage (numéro + email) non transmissible par merge field (lookup 3 niveaux), champs SECO 1.141/1.65 vides
  - Prochaine action : retravailler le design du template PDFMonkey ASO (retour Thomas 2026-07-14 : le modèle fonctionne mais le design n'est pas bon ; attendre ses précisions ou un screenshot) ; ensuite finaliser + envoyer le draft « Feedbacks ASO+ » (bullet FED-70129 à passer en « c'est en place ») ; test Modèle = MMT optionnel (fix caisse b2cbe75 jamais testé)

Retard 11j · 13.07 +lm @claude-config

  - Contexte : TXT twilio.lausanne.marketing (jeton twilio-domain-verification=ec50fc5b...) posé le 2026-07-10 dans la zone Cloudflare LM, servi publiquement (vérifié via Google et Cloudflare DoH, valeur strictement identique au jeton), mais le vérificateur Twilio renvoyait encore « There was an error verifying this domain » le jour même : cache interne côté Twilio soupçonné
  - Étape 1 : Twilio One Console, Organization settings, Domains, lausanne.marketing, bouton « Check verification »
  - Étape 2 si toujours Unverified : supprimer l'entrée du domaine chez Twilio et la recréer en méthode DNS ; un nouveau jeton sera généré : mettre à jour le TXT twilio de la zone lausanne.marketing (compte Cloudflare LM, zone active, effet immédiat)
  - Étape 3 si échec persistant : ticket au support Twilio en signalant que twilio.lausanne.marketing répond publiquement sur n'importe quel résolveur
  - Au passage : vérifier que intuify.ch est passé de « Verified (Uncertain) » à « Verified » (vérifié pendant la fenêtre de bascule des NS Infomaniak vers Cloudflare du 2026-07-10, le statut devrait se consolider tout seul)

Retard 10j · 14.07 +lm @n8n

  - Dimension : sast (High)
  - Fichier : /home/runner/work/lm-security/lm-security/lm-security/.work/n8n/.github/workflows/sync-to-n8n.yml:104
  - Référence : yaml.github-actions.security.run-shell-injection.run-shell-injection
  - Action : vérifier et corriger

Retard 10j · 14.07 +lm @claude-config

  - Dimension : sast (High)
  - Fichier : /home/runner/work/lm-security/lm-security/lm-security/.work/claude-config/project/hooks/dispatcher.js:60
  - Référence : javascript.lang.security.detect-child-process.detect-child-process
  - Action : vérifier et corriger

Retard 10j · 14.07 +lm @lm-presentation

  - Dimension : sast (High)
  - Fichier : /home/runner/work/lm-security/lm-security/lm-security/.work/lm-presentation/scripts/export-pdf.mjs:45
  - Référence : javascript.lang.security.audit.spawn-shell-true.spawn-shell-true
  - Action : vérifier et corriger

Retard 10j · 14.07 +lm @lm-presentation

  - Dimension : sast (High)
  - Fichier : /home/runner/work/lm-security/lm-security/lm-security/.work/lm-presentation/scripts/export-pdf.mjs:67
  - Référence : javascript.lang.security.audit.spawn-shell-true.spawn-shell-true
  - Action : vérifier et corriger

Retard 10j · 14.07 +lm @lm-presentation

  - Dimension : sast (High)
  - Fichier : /home/runner/work/lm-security/lm-security/lm-security/.work/lm-presentation/scripts/export-pdf.mjs:79
  - Référence : javascript.lang.security.audit.spawn-shell-true.spawn-shell-true
  - Action : vérifier et corriger

Retard 10j · 14.07 +lm @calculator-health

  - Dimension : sast (High)
  - Fichier : /home/runner/work/lm-security/lm-security/lm-security/.work/calculator-health/backend/Dockerfile:12
  - Référence : dockerfile.security.missing-user.missing-user
  - Action : vérifier et corriger

Retard 10j · 14.07 +lm @calculator-health

  - Dimension : sast (High)
  - Fichier : /home/runner/work/lm-security/lm-security/lm-security/.work/calculator-health/poc/Dockerfile:18
  - Référence : dockerfile.security.missing-user.missing-user
  - Action : vérifier et corriger

Retard 10j · 14.07 +proactif @mafondue

  - Import test du 2026-07-13 : 9 Comptes + 1 Contact (David Leresche) créés dans Zoho depuis les 10 contacts Bexio les plus récents via le subflow de prod (pivot bexio_contact_id, Statut Actif, Source Bexio, sync_mapping remplie, re-run = 0 upsert). Jugement métier à porter sur le mapping des champs, avec Fabien si possible
  - Décision à prendre avant le seed complet : réintroduire ou non Phone + Website sur Comptes et Mobile sur Contacts (natifs masqués hors ERD, valeurs perdues silencieusement à l'import : David Leresche n'a aucun numéro dans le CRM), et sort de l'email société (pas de champ natif sur Comptes, pattern Contact technique pas dans l'ERD actuel)
  - Layouts du 2026-07-13 : section Informations à cacher (Créé par, Modifié par, Devise, Taux de change) posée sur Prospects, Contacts et Offres ; option pour finir comme Comptes : supprimer la section Google AdWords en UI sur ces 3 modules (intouchable par API), puis retrait complet de Devise et Taux de change possible sur Prospects et Contacts
  - Zoho Campaigns : une sync est active et envoie actuellement des contacts ; vérifier son périmètre (sync CRM vers Campaigns, listes, campagnes en cours) et l'impact avant le seed complet Bexio, risque que les contacts importés partent en campagne email
  - Réfs : mafondue/crm-zoho/STATUS.md (sections Audit de structure et Harmonisation layouts), lm-stack/n8n clients/mafondue/CLAUDE.md (état Phase B de la sync)

Retard 9j · 15.07 +proactif @n8n

  - Décision Thomas (nuit du 14 au 15.07, fin de session 69ddf03a-be3e-436c-8971-72f977b71eaa) : arrêter l'approche fonctions Deluge one-shot (tâtonnements, Test Run qui ne transmet pas les arguments, éditeur qui réécrit le code, lag d'indexation invisible) et repartir sur des workflows n8n de cleaning déclenchables d'un clic
  - Fonctions Zoho à SUPPRIMER (via MCP deleteFunction, les .dg restent dans zoho-helper comme référence, commits 9c74cc7 et 4395b7b) : reconcilierseancesgo (790258000012345018), purgerdoublonsseancesgo (790258000012384008), reconcilieretudiantsgo (790258000012362002), purgerseancesorphelinesgo (790258000012337020), reconcilieretudiants et purgerseancesorphelines (ids via getFunctions)
  - À GARDER tel quel : le contrôle de cohérence en prod (checkcoherencecreatorcrm + checkcoherenceentite + executercontrolecoherence, schedule quotidien 05h00, email vers hello@lausanne.marketing seulement si anomalie)
  - MYSTÈRE à élucider AVANT toute purge de données : les 3 runs enchaînés de reconcilierseancesgo ont POSTé environ 300 miroirs séances (code 3000 + ID confirmés dans les logs) mais purgerdoublonsseancesgo voit 0 doublon dans All_Sessions_API ; hypothèse dominante : criteria/filtre sur le report All_Sessions_API qui masque ces records (vérifier dans le builder Creator) ; vérif rapide : count de « Toutes les séances » (Seances_List) dans l'UI et chercher « Test Fide » en doublon
  - Workflows n8n à créer (déclenchement manuel/bouton, logique éprouvée des .dg) : détection manquants/orphelins/doublons en lisant Seances_List paginé (PAS All_Sessions_API), purge DELETE v2.1 par critère + skip_workflow, recréation POST Seances_Form v2.1 avec mapping picklist actual vers display et salle « Libre » par défaut
  - Reste à réconcilier (chiffres du contrôle du 14.07) : Séances environ 93 manquantes + doublons éventuels ; Cours 12 manquants (3 ASO+, 9 dispatch KIM) + 2 orphelins de test à purger (courstest, COURSASOTEST2) ; Inscriptions 26 manquants ; Suivis 347 manquants + 114 orphelins + 543 doublons ; Étudiants solde 9 (4 fiches test yopmail à supprimer côté CRM, 3 doublons Valentina à fusionner, Axelle Barman et Rayan Abdullahi en attente de la réponse d'Anne-Laure pour leurs coordonnées)

Retard 9j · 15.07 +proactif @n8n

  - Le repointage du subflow Mandant a cassé les préinscriptions KIM avec conseiller pendant 8h le 14.07 (INVALID_DATA sur Conseiller) ; celle de 15h24 (Lucas Fortin) a été rejouée avec succès le 15.07 après pose du Statut Conseiller·ère sur la fiche Lauren Cordey
  - Vérifier les Executions des 2 parents Préinscription KIM (Fr QcskBKWcRIVfBCdP, En nBMBkXvtaHITJwyC) sur la fenêtre : retry « with currently saved workflow » des échecs restants ; si erreur FILTER_CRITERIA sur le conseiller, poser d'abord Statut = Conseiller·ère sur sa fiche Partenaires

Retard 9j · 15.07 +proactif @n8n

  - Soumettre une Offre gratuite de test avec Audience Enfant puis vérifier : fiche parent sur layout Représentant·e légal·e (aucun miroir Creator, sortie no-op des Switch Contact), fiche enfant sur layout Enfant (Statut Enfant, lookup représentant rempli, alias email parent+enfant@), miroir Etudiants_Form dans Creator, zéro erreur n8n
  - Rail déployé le 15.07 (commit 4a7832a3) ; spec : zoho-helper/clients/proactif/docs/specs/2026-07-14-layout-enfant-module-partenaires-design.md

Retard 9j · 15.07 +proactif @mafondue

  - Support de séance : mafondue/crm-zoho/meeting-2026-07-15.md (6 décisions + annexes + déroulé post-meeting), état technique complet dans crm-zoho/STATUS.md
  - Décisions attendues : champ Axes multiple unique (Prospects/Comptes/Contacts), nettoyage des doublons Bexio dans Bexio par Mathieu (SV Suisse x5, liste des doublons probables à générer par nous), mapping des groupes ENTREPRISE/GMS/DIVERS/FDG/LAITERIE TERROIR + statut des fiches _PROSPECT, GO import audience Campaigns (16 227 Prospects prêts dans crm-zoho/audience/), remise en service du formulaire newsletter mafondue.ch (cassé : accès site à obtenir, rebrancher vers le CRM avec opt-in daté), gestionnaire de mots de passe Bitwarden (OK de principe + admin)
  - Questions clés : signification de MBG et FDG, ventes e-commerce dans Bexio ou pas, fournisseurs à importer ou exclure, taux EUR à confirmer (1 EUR = 1.081522 CHF), périmètre factures (historique 2019+ ou exercice courant), 2 sièges Zoho à ajouter (1 seul payé, 3 prévus à l'offre), emailing des clients sociétés = activer la piste interlocuteurs (Campaigns n'adresse pas les Comptes)
  - Après la séance : exécuter les arbitrages (champ Axes environ 2h, mappings manquants, liste doublons pour Mathieu, import audience si GO), reporter les décisions dans STATUS.md et retirer la note de l'index DOCS.md
  - Côté Thomas indépendamment du meeting : corriger la connexion Zoho « n8n » en UI (débloque le sens Zoho vers Bexio), go changelog ERD (champ Email sur Comptes, diagramme en attente de push), trancher le fallback mobile vers Téléphone pour les sociétés sans fixe
  - État sync au 14.07 : import test HORECA validé (236 fiches avec axes, statuts, cantons, rattachements), factures testées sur les 3 cas (société CHF, personne, EUR), 213 Comptes dans le CRM, seed complet prêt à 2 passes

Retard 9j · 15.07 +lm @lm-security

  - TRIAGE des 53 findings « secret » fait le 2026-07-23 (sous-agent, valeurs masquées) : findings granulaires retirés de l'inbox, git garde l'historique. Bilan : 7 vrais secrets, 5 faux positifs, reste = doublons et artefacts de scan
  - Vrais secrets PRÉSENTS dans le working tree : 4 secrets HMAC de webhook Typeform en clair dans staticData des workflows « Typeform to SMTP » lm (zSxezPcaynzogQxD / NQyRojj2o7PB2seA / DgrXAinizlwJtSEm / 9IvoyPSPVYSLw0lm, ligne 84). Rotation = désactiver puis réactiver le Typeform Trigger dans n8n (régénère le secret) puis re-commit ; impact faible (forger une soumission = un email de confirmation). Point structurel : n8n committe webhookSecret en clair dans staticData, à exclure du sync sinon la valeur régénérée re-fuite
  - Vrais secrets en HISTORIQUE git seulement (fichiers supprimés) : token Digiforma (qIEz5it3gP2ZNrQx) et clé Supabase (7dk1fdYvJwZGmvP5) = les « 2 JWT morts » déjà révoqués ; zapikey Zoho (L87Cnk4XfHdOCb61, dup archivée) à vérifier côté Zoho puis régénérer si encore valide. Tous neutralisés par la purge d'historique n8n
  - Faux positifs confirmés (ne pas re-traiter ; poser une exclusion côté moteur lm-security) : subflows « Zoho Upload » actuels proactif (3BZcBFfWQvsNkC3b) et execed (7rCIM0fiAO26EHs4) = références credential OAuth2/BasicAuth, pas des valeurs ; state.json:4534 = SHA de commit git dans le cache du moteur d'audit
  - Exécuter la purge de l'historique n8n (2 JWT morts) dès qu'aucune session Claude n'est active sur le repo : procédure prête dans lm-security/docs/procedures/purge-historique-n8n.md, outillage installé (Python 3.12 + git-filter-repo), TODO dédié déjà dans l'inbox
  - Décider du sort des clés encore ouvertes : 4 clés des workflows Typeform to SMTP (lm) et clé du subflow Zoho Upload ExecEd : rotation côté fournisseur si encore utilisées, sinon même purge d'historique
  - Subflow « Zoho (Upload document) » : correction prévue avec Thomas en supprimant la fonction (TODO existant dans ce sens)
  - Poursuivre sur le reste du rapport email du matin : environ 106 TODO High/Critical encore dans l'inbox (deps et SAST High) et les findings Medium du rapport (branch protection absente sur la quasi-totalité des repos, collaborateurs externes vaumarcus et ybcs-website)
  - Déjà fait le 2026-07-14 : vitest 3.2.7 sur 5 repos, lm-presentation passé en privé, historique claude-config purgé (snyk), bloc env de settings.local.json exclu du sync