CHANGELOG

## 2026-10-20 - LeadTracker AWM 1.11.76 - Destinations CRM externes facultatives
- Le tableau de câblage n affiche plus **Capturia · Google — Destination à configurer** sur toutes les campagnes.
- Capturia apparaît uniquement lorsqu il est réellement actif en lecture et/ou en transfert sortant pour la campagne.
- **CRM Client AWM** n est plus affiché en grisé lorsqu il ne s applique pas au client.
- Le KPI devient **CRM externes** afin de ne pas figer l architecture sur Capturia.
- LeadTracker AWM demeure toujours la destination opérationnelle de base; aucun changement au moteur Capturia immédiat validé terrain.

## 2026-10-20 - LeadTracker AWM 1.11.75 - Capturia Identity Mapping v2
- Confirmation terrain recue : un nouveau lead VMV entre maintenant immediatement dans Capturia; le flux central temps reel reste inchange.
- Corrige le mapping ou Capturia pouvait afficher le courriel comme `first_name` lorsque le formulaire ne fournissait pas un prenom reconnu.
- Un nom candidat est maintenant refuse s il ressemble a un courriel, telephone ou URL.
- Nouveaux alias : `Nom du lead`, `Nom du prospect`, `Nom du contact`, `lead name`, `contact name`, `client name`, plus Prenom/Nom de famille FR/EN.
- Un nom complet est decoupe proprement en prenom/nom. Si un seul nom humain est disponible, il devient l identite visible plutot que le courriel.
- Aucun contact historique Capturia n est rejoue ou modifie automatiquement; la correction s applique aux prochains leads.

## 2026-10-19 - LeadTracker AWM 1.11.74 - paquet runtime allégé et historique hors plugin

- Le plugin livré ne conserve plus les dizaines de fichiers RELEASE-NOTES/VALIDATION des anciennes versions.
- Le paquet runtime garde uniquement le code courant, `README.md`, `CHANGELOG.md`, `ROADMAP.md`, les notes/validation de 1.11.74 et `data/history` requis par les outils de migration/rapprochement.
- Les documents historiques sont archivés hors du plugin installé; aucune donnée de migration n'est supprimée.
- Aucun changement métier par rapport à 1.11.73 : Leads = Appels + Formulaires, fiche complète au clic, CPL, Google Ads, Capturia et routage restent inchangés.
- Règle permanente : une nouvelle version ne doit jamais réembarquer les notes/validations unitaires de toutes les versions précédentes.

## 2026-10-19 - LeadTracker AWM 1.11.73 - correctif packaging securise

- Aucun changement fonctionnel par rapport a 1.11.72 : la vue Leads unifiee appels + formulaires et la fiche detaillee au clic sont conservees.
- Le paquet 1.11.72 contenait par erreur deux copies byte-for-byte identiques du module (`calltracker_new/` et `awm-calltracker/`), ce qui portait la taille extraite a environ 381 Mo et declenchait la limite Core de 256 Mo par module.
- Le paquet 1.11.73 ne contient qu une seule racine livrable `awm-calltracker/`; les arbres de travail sont exclus.
- La limite Core n est pas relevee ni contournee : le packaging est corrige a la source.

## 2026-10-19 - LeadTracker AWM 1.11.72 - leads unifies appels + formulaires et fiche detaillee

- La section « Leads de la campagne » additionne maintenant les appels entrants et les formulaires, selon la meme definition que le CPL : appels entrants + formulaires.
- Les compteurs affichent Leads totaux, Appels, Formulaires, puis le detail des moteurs de formulaires.
- Les 20 derniers leads sont fusionnes dans une seule chronologie, avec badge Appel/Formulaire et heure Toronto.
- Un clic sur n importe quel lead ouvre sa fiche detaillee sans quitter la campagne.
- Formulaire : nom, courriel, telephone, formulaire, source, page, statut, message, sujet, reponses completes du payload et references utiles; secrets/token/captcha/API restent filtres.
- Appel : appelant, numero suivi, statut, duree, localisation, Call SID, Child SID, enregistrement protege quand disponible et etapes de routage.
- Les appels ne sont jamais presentes comme des preuves Capturia; Capturia reste applicable aux formulaires VMV-NAT seulement.

## 2026-10-19 - LeadTracker AWM 1.11.71 - liaison Google Ads persistante et historique CPL automatique

- Une association Google Ads devient une configuration persistante : MCC, compte client, mode compte/campagnes et sélection de campagnes sont mémorisés avec une empreinte stable et un historique de liaison.
- Toute modification de cette association déclenche automatiquement un worker de récupération de tout l historique Google Ads disponible, du premier mois réellement observé jusqu au mois courant, sans limiter le recalcul au mois courant/précédent.
- Chaque mois est réconcilié avec le barème AWM officiel 50/40/30/20/15; le rabais continue de s appliquer sur les frais de gestion, jamais sur l investissement.
- Les lignes CPL plus anciennes que la fenêtre vérifiable Google Ads ne sont jamais supprimées ni écrasées.
- Chaque mois conserve désormais des instantanés de résultat Google Ads/CPL : investissement, frais, rabais, coûts annexes, appels, formulaires, leads, coût total et CPL calculé. Le premier résultat reste conservé et les vérifications ultérieures sont auditées.
- Le worker est idempotent par empreinte de configuration et conserve son état (en attente, en cours, complet, partiel ou erreur) pour diagnostic.
- Hub AWM 4.5.90 complète ce contrat en empêchant un enregistrement partiel de vider silencieusement un compte Google Ads déjà associé et en affichant l état de l historique directement dans la campagne.

## 2026-10-18 - LeadTracker AWM 1.11.70 - campagne active = synchronisation automatique

- Nouvelle règle opérationnelle : une campagne publiée dont le statut LeadTracker est `active` doit maintenir automatiquement ses entrées configurées sans clic sur « Synchroniser ».
- Numéro Twilio : à l’activation ou après une modification de campagne, LeadTracker applique le routage entrant puis relit Twilio pour vérifier que le VoiceUrl AWM est réellement actif. Les erreurs restent visibles dans `_callink_twilio_sync_error`; aucune réussite n’est inventée.
- Formulaires : pour toute campagne active ayant des associations/form capture configurées, LeadTracker rafraîchit les inventaires Hub Client, rapproche les formulaires déjà reçus et réapplique les mappings enregistrés. Aucun formulaire non rattaché n’est deviné automatiquement, sauf la règle spéciale VMV-NAT `capturia_auto_all_forms` déjà existante.
- Un worker de convergence traite les changements immédiatement en arrière-plan et recontrôle ensuite les campagnes actives par petits lots. Le numéro est revalidé périodiquement et les formulaires sont rafraîchis sans dépendre d’un opérateur.
- Les changements de statut, numéro, destination, client, mappings ou activation de capture déclenchent automatiquement la convergence de la campagne.
- Le bouton manuel « Synchroniser les formulaires » reste disponible uniquement pour forcer un diagnostic/scan immédiat.
- Hub Client 1.14.33 complète ce contrat : mappings actifs actualisés en arrière-plan et lecture fraîche obligatoire juste avant chaque vraie soumission Elementor, Gravity Forms, Contact Form 7 ou hook AWM.

## 2026-10-18 - LeadTracker AWM 1.11.69 - moteur Capturia central temps réel

- Les nouveaux leads VMV-NAT sont maintenant envoyés à Capturia directement par LeadTracker, dans la même requête que `forms/submit`, via le moteur central déjà utilisé pour la reprise des 563 formulaires historiques.
- Le lead exact est mis en file idempotente par `campaign_post_id + form_row_id`; aucun ancien lead n'est rejoué automatiquement.
- Le chemin normal ne dépend plus d'un second appel mutatif depuis Hub Client : Hub Client reçoit `central_owned=1` et n'a pas le droit de créer un deuxième contact.
- Une preuve centrale est écrite avant l'appel API puis enrichie à chaque étape : Contact, Google, Données, contact_id, request-id, HTTP et heure Toronto.
- En cas de 429, seul le lead exact est replanifié. Une réponse réseau/mutative incertaine reste arrêtée sans rejeu aveugle.
- En mode confidentialité CRM Client AWM, LeadTracker crée et tague le contact puis Hub Client 1.14.32 ajoute uniquement les réponses complètes depuis le miroir local chiffré au même contact et met à jour la même preuve.

## 2026-10-16 - LeadTracker AWM 1.11.68 - preuve Capturia renforcée par lead

- La colonne Capturia affiche maintenant, quand disponibles, l'identifiant du contact Capturia, l'identifiant de requête API, le code HTTP et l'heure de livraison en plus de `Contact ✓ · Google ✓ · Données ✓`.
- Le tableau « Preuve des nouveaux formulaires » expose aussi le request ID et HTTP afin de fournir une preuve technique exploitable sans accès au tableau de bord Capturia.
- `delivery_for_form_ids()` transporte maintenant `request_id` jusqu'à la ligne exacte du lead.
- Aucun envoi supplémentaire n'est généré par l'affichage : la preuve provient uniquement du reçu authentifié envoyé par Hub Client après la vraie tentative Capturia.

## 1.11.67 — Campagne déjà ouverte : accès direct leads/export (2026-10-16)
- Dans Câblage des leads, si la campagne sélectionnée est déjà celle de l'URL `lt_campaign`, le bouton principal devient « Voir les leads / Export » et pointe uniquement vers l'ancre locale `#lt-editor-{id}`.
- Évite un rechargement inutile et empêche le loader Hub de croire à une nouvelle navigation pour la même campagne.
- Les autres campagnes conservent « Gérer dans LeadTracker » avec la navigation complète habituelle.
- Aucun changement aux exports CSV 1.11.66, Capturia, formulaires, CPL, Twilio ou historiques.

## 2026-10-16 - LeadTracker AWM 1.11.66 - export funnel complet avec Capturia

- Corrige l export CSV de campagne afin d inclure les leads déjà envoyés ou déjà présents dans Capturia, au lieu de les exclure.
- L export fusionne les soumissions LeadTracker et les archives Capturia de la campagne, en privilégiant la ligne formulaire comme source principale.
- Déduplication conservatrice : lien technique contact/formulaire quand disponible; sinon même courriel ou téléphone normalisé dans une fenêtre maximale de 24 h, en un-à-un.
- Un lead présent uniquement dans Capturia reste dans le CSV avec la provenance `Archive Capturia uniquement`; il n est pas perdu.
- Nouvelles colonnes client : Présent dans Capturia, Statut Capturia, ID contact Capturia et Provenance export.
- Les filtres Du/Au et le choix des formulaires rattachés sont conservés. Un contact Capturia lié à un formulaire décoché ne peut pas être réintroduit par l archive.
- `capturia_unassigned` reste exclu car il n appartient pas encore à la campagne VMV-NAT.
- Export strictement en lecture seule : aucun courriel, aucun appel API Capturia et aucune mutation de lead.

## 2026-10-16 - LeadTracker AWM 1.11.65 - export CSV par campagne

- Nouvelle section **Export CSV des formulaires** directement sous la liste des leads d'une campagne.
- Choix de la période (Du/Au) et des formulaires rattachés, tous présélectionnés par défaut.
- Export client lisible: identité, téléphone, formulaire, page d'origine, message et champs de formulaire, sans secrets techniques ni contacts importés de Capturia.
- CSV UTF-8/Excel FR-CA, protection anti-injection et limite de sécurité de 25 000 lignes.
- Aucun envoi, courriel ou mutation n'est déclenché par l'export.

## 2026-10-16 - LeadTracker AWM 1.11.64 - ordre d'envoi Capturia autoritaire dans forms/submit

- Corrige le cas terrain où LeadTracker recevait immédiatement le formulaire VMV-NAT mais Hub Client n'obtenait aucune preuve Capturia.
- La réponse authentifiée `forms/submit` transporte maintenant une instruction PII-free `capturia_dispatch` calculée sur Alliance pour la campagne exacte qui vient d'être enregistrée.
- Cause racine terrain supplémentaire corrigée : `connector_vmv_credential()` exigeait encore au moins un mapping formulaire individuel alors que VMV-NAT est maintenant en mode `capturia_auto_all_forms`. Cette ancienne garde pouvait accepter le lead dans LeadTracker puis refuser silencieusement la credential Capturia. La route auto-all-forms n exige plus de mapping individuel sur le WordPress principal VMV.
- Hub Client n'a plus besoin de redécouvrir l'intention Capturia via une seconde lecture de `forms/campaigns` avant l'envoi; un cache, une synchronisation de mappings ou une lecture transitoire ne peut donc plus annuler silencieusement la livraison.
- L'instruction ne contient jamais la clé API. Elle indique uniquement demandé/autorisé, campagne, mode tous formulaires et, en cas de blocage, un code/message technique.
- Si la route centrale est invalide, le prochain Hub Client peut enregistrer une preuve `Bloqué` avec la raison exacte au lieu de laisser le lead en `Sans preuve`.
- Corrige aussi le repli des anciennes clés par campagne : si VMV-NAT ne porte pas elle-même le secret mais qu une seule connexion Capturia du même client existe, le Connector réutilise cette source autorisée au lieu de retourner `clé illisible`.

## 2026-10-15 - LeadTracker AWM 1.11.63 - Capturia automatique pour tous les formulaires VMV-NAT

- Le contrat Connector annonce `capturia_auto_all_forms` pour VMV-NAT lorsque la destination Capturia est active.
- Le câblage n exige plus de sélectionner manuellement chaque formulaire VMV-NAT : Hub Client capture automatiquement les formulaires du site principal, tout en respectant une association explicite à une autre campagne.
- Activer Capturia maintient la réception LeadTracker active pour la campagne; désactiver Capturia redevient un choix explicite.
- Les preuves restent rattachées au lead exact et affichées en America/Toronto.

## 2026-10-15 - LeadTracker AWM 1.11.62 - preuve Capturia par lead et heure Toronto

- Corrige l affichage des heures VMV-NAT : les horodatages techniques restent en UTC mais la page Cablage des leads les affiche maintenant via l horloge Core America/Toronto avec HAE/HNE automatique.
- La liste des leads VMV-NAT ajoute une colonne Capturia par formulaire : Confirme, En attente, Bloque, A confirmer ou Aucune preuve technique recue.
- La preuve expose les etapes techniques Contact / Google / Donnees afin de distinguer creation du contact, etiquette et notes sans ouvrir Capturia.
- Le recu technique accepte source, identifiant de formulaire, phase et curseur de notes; il reste strictement sans nom, courriel, telephone ni contenu de formulaire.
- Le connecteur accepte un submitted_at_utc explicite. Une resoumission idempotente recente peut reconciler l heure UTC et completer nom/courriel/telephone manquants sans creer un doublon.
- Le cablage Capturia VMV-NAT accepte maintenant tout formulaire explicitement associe sur le site principal parmi Elementor, Gravity Forms et Contact Form 7; le moteur du formulaire ne peut plus etre un motif de rejet silencieux.
- Aucun historique 563 n est relance par cette version.

## 2026-10-15 - LeadTracker AWM 1.11.61 - vrai contact Elementor et séparation CRM / preuve

- Les nouveaux formulaires Hub Client utilisent le vrai **nom, courriel et téléphone** lorsque ces données existent; `Demande Web` devient le dernier recours uniquement si aucune identité exploitable n est disponible.
- Les libellés Elementor français/anglais courants sont reconnus : nom complet, prénom/nom, courriel/email, téléphone/cellulaire/mobile et variantes proches.
- En mode `local_mirror_v1`, LeadTracker conserve seulement l identité opérationnelle minimale nécessaire à l affichage et à la déduplication; les réponses complètes restent dans le miroir local chiffré et sont envoyées au CRM Capturia pour VMV-NAT.
- La table de preuve Capturia demeure sans PII et continue d afficher uniquement le statut de livraison, les identifiants techniques et les horodatages.
- Les journaux ajoutent seulement des indicateurs booléens `identity_*_present`; aucune valeur nominative n est écrite dans le journal de sécurité.
- La récupération de tous les contacts Capturia manquants de 1.11.60 est conservée sans changement.

## 2026-10-15 - LeadTracker AWM 1.11.60 - Capturia : preuve des nouveaux envois et récupération des archives manquantes

- Ajoute dans **Câblage des leads > VMV-NAT** une preuve technique des nouveaux formulaires envoyés vers Capturia : statut, identifiant de ligne AWM, identifiant contact Capturia et horodatage, sans stocker de nouvelle copie nominative dans la table de preuves.
- Ajoute **Récupérer tous les leads Capturia manquants** : AWM parcourt tous les contacts lisibles par la clé API Core de Vendre Maison Vite, compare les identifiants Capturia et les formulaires déjà connus, puis importe uniquement les contacts absents de l archive courante.
- Les contacts déjà issus des 563 formulaires historiques acceptés ou des nouveaux formulaires AWM sont reliés à leur ligne existante plutôt que dupliqués.
- Une attribution de campagne ambiguë n est jamais forcée : le contact est conservé comme **Capturia - à classer** au niveau du client et reste hors CPL jusqu à qualification.
- Le scan respecte les pauses HTTP 429 et reprend par WP-Cron / AJAX. Aucun scan ni nouvel envoi n est lancé à l installation.
- VMV-NAT reste une campagne SEO pour le CPL; `Google` reste uniquement la destination Capturia.

## 2026-10-15 - LeadTracker AWM 1.11.59 - Capturia : reprise adaptive apres HTTP 429

- La reprise historique VMV-NAT n envoie plus plusieurs formulaires simultanement : un seul formulaire est traite par passage, avec espacement des requetes d ecriture.
- Capturia HTTP 429 n est plus traite comme une erreur fatale : LeadTracker lit `Retry-After` / `RateLimit-Reset` quand disponible, applique une pause globale, puis reprend automatiquement.
- Le navigateur et WP-Cron partagent un verrou de traitement afin d eviter deux workers Capturia concurrents sur la meme campagne.
- Les lignes deja acceptees restent acquises; les lignes en attente/retry conservent leurs cles d idempotence. Aucun formulaire n est reinitialise par la mise a jour.
- Pendant un backfill actif, le bouton de verification Capturia ne lance plus de nouvelles requetes inutiles : il affiche l etat du transfert et la pause eventuelle.
- Aucun envoi Capturia n est declenche a l installation. VMV-NAT reste SEO pour le CPL et Capturia reste reserve a Vendre Maison Vite.

## 2026-10-15 - LeadTracker AWM 1.11.58 - Cablage Capturia lit correctement la cle Core

- Corrige le faux message « La cle API Capturia est absente ou illisible » dans **Cablage des leads > VMV-NAT** alors que la meme cle est validee dans Core AWM et dans la fiche campagne.
- Cause : une connexion Capturia geree par Core n appartient volontairement a aucune campagne (`campaign_id=0`). Le bouton de verification transmettait ce `0` au moteur Capturia, qui ne pouvait alors pas retrouver le client Vendre Maison Vite ni la cle Core.
- Correction : la verification utilise VMV-NAT comme contexte de campagne lorsque la credential vient de Core; le chemin historique conserve son identifiant de campagne d origine.
- L interface indique maintenant explicitement « Cle Capturia geree dans Core AWM pour Vendre Maison Vite » au lieu de « campagne #0 ».
- Aucun changement de cle, aucun envoi Capturia et aucun backfill ne sont executes a l installation. La reprise historique 564 formulaires de 1.11.57 reste manuelle et idempotente.


## 2026-10-15 - LeadTracker AWM 1.11.57 - VMV-NAT : reprise des 564 formulaires vers Capturia Google

- Ajoute une reprise historique manuelle et idempotente pour **VMV-NAT uniquement** : les formulaires deja rattaches a la campagne sont figes dans un instantane puis envoyes par lots vers Capturia avec l etiquette normale **Google**.
- Le traitement conserve un etat technique par formulaire (sans PII), reprend apres interruption et stoppe les resultats reseau incertains au lieu de rejouer aveuglement une creation.
- Les formulaires dont la source est deja `capturia` ne sont jamais renvoyes. Un formulaire sans courriel ni telephone reste bloque et visible dans le bilan.
- Avant le premier envoi, LeadTracker exige une confirmation explicite que l import historique ne declenchera pas une sequence SMS/courriel indesirable dans Capturia.
- Le statut commercial CRM **Actif/Inactif** est desormais independant des campagnes et des leads : `Inactif` ne bloque plus l activation de campagne, Capturia ou la collecte. Un dossier archive/supprime ou un rattachement non canonique reste bloque.
- La campagne reste classee **SEO** pour le CPL. La destination Capturia `Google` ne transforme pas VMV-NAT en campagne Google Ads.
- Aucun envoi n est lance a l installation : l operateur doit ouvrir Cablage des leads > VMV-NAT et confirmer la reprise.

## 2026-10-15 - LeadTracker AWM 1.11.56 - Capturia gere dans Core

- LeadTracker ne propose plus de champ pour enregistrer/remplacer la cle Capturia. Le bouton ouvre `Core AWM > Connexions > Coffre et cles`.
- Pour les campagnes du client CRM **Vendre Maison Vite**, la cle centralisee Core est lue en priorite en memoire serveur.
- Les anciennes cles chiffrees par campagne restent lisibles temporairement comme repli, sans nouvelle ecriture dans LeadTracker.
- Un remplacement de cle dans Core invalide uniquement les caches de capacites/compte/sources; aucun lead historique ni mapping CPL n est purge.
- La planification Capturia reconnait aussi une campagne active utilisant la cle Core meme si aucun ancien meta de cle n existe.
- Capturia n est pas active pour les autres clients.

## 2026-10-14 - 1.11.55 / Suite AWM 4.5.404 - CRM Clients

Nouvelle vue CRM Clients - resultats, en lecture directe sans cache nominatif. Les lecteurs et collecteurs historiques restent disponibles.

Candidate de migration additive : tests locaux, essai WordPress/MySQL et sites clients requis.
Aucun transfert a l'installation. Ne supprime ni sources historiques, ni audio Twilio.
Un seul lancement global depuis CRM AWM > CRM Clients - campagnes et leads.
Prealables : trousseau Core enrole et sauvegarde separement; Hub Client 1.14.22 sur sources et destination; autorisations techniques.
Le statut commercial et le statut des campagnes ne sont pas modifies. Capturia n'est jamais exige ni active pour les autres clients.

---

## LeadTracker AWM 1.11.54 — Statut client CRM canonique à l'activation de campagne (13 octobre 2026)
- La garde d'activation respecte le statut CRM du véritable dossier client `callink_client`; un CRM Actif n'est plus bloqué par `_callink_status=disabled` ou `_callink_manual_inactive=1` hérités.
- Client absent, supprimé, avec mauvais rôle ou non canonique : activation refusée avec identifiant et message de rattachement; CRM Inactif/Archivé et campagnes brouillon/archivées restent refusés.
- Aucun rapprochement ni mutation automatique du `client_id` historique; si le lien de campagne pointe vers un autre dossier, la réconciliation doit être vérifiée séparément.
- Aucun recalcul CPL, aucune réattribution de lead, et aucun envoi Capturia dans cette version.

## 1.11.53 — Correctifs UI statut et périmètre Capturia — 2026-10-13
- Bouton de statut réel dans Modifier et Câblage, action AJAX confirmée, retour visuel instantané, réponse d'erreur non trompeuse.
- Liste campagnes : confirmation avant clic, état attendu/choisi explicites.
- Capturia masqué sur les campagnes non configurées; détails limités à l'usage pertinent.
- Contrôles WordPress/Core AWM/CRM et journal opérateur + timestamp + avant/après, mise à jour conditionnelle en base.
- Pas de migration ni de modification silencieuse des campagnes, formulaires, Capturia, numéros ou CPL.
- Test unitaire local terminé, déploiement terrain et publication roadmap publique à confirmer.

## 1.11.52 — Trois statuts distincts dans les campagnes — 2026-10-13
- Trois indicateurs indépendants dans l’éditeur de campagne et dans « Câblage des leads » : session WordPress Alliance, état métier `_callink_status`, Capturia lecture/écriture/validation.
- « Connexion active » n’est plus affiché comme preuve que la campagne reçoit des leads. Les campagnes en pause restent en pause, aucun lead ni CPL modifié.
- Les permissions Capturia absentes sont présentées comme « inconnues » et non comme lecture seule certaine. Une vérification en lecture ne valide jamais un envoi réel; messages d’avertissement cohérents.
- Libellés et pastilles accessibles, responsives et adaptés aux modes clair/sombre. Validation terrain et publication effective de la roadmap publique en attente.

## 1.11.51 — VMV-NAT (SEO) vers Capturia Google avec connexion existante — 2026-10-12
- Gestion directe sur LeadTracker → Câblage des leads → VMV-NAT (#2636) : formulaires, leads, source CPL, historique et rapprochement strictement manuel des leads non attribués.
- Nouveau choix explicite « Activer le routage automatique des nouveaux leads SEO vers Capturia Google » ; obligation de source SEO et formulaire Elementor du site principal, sans activer silencieusement une campagne en pause.
- Réutilise la clé Capturia du même client CRM déjà chiffrée dans Core AWM, sans champ de mot de passe ou nouvelle clé. Résolution refuse les secrets d'autres clients et les comptes ambigus.
- Publie les champs `marketing_source` et `capturia_requested` sur l'API Connector sécurisée pour le site VMV principal ; ne change pas les soumissions ni coûts Google Ads.
- Les envois Capturia sortants sont réalisés par Hub Client sur la base de soumissions locales chiffrées, uniquement après validation scopes d'écriture + étiquette Google. Envois réels non vérifiés sur le tenant.

## 1.11.51 — VMV-NAT : configuration et leads depuis le câblage — 2026-10-12
- Vue de configuration directement dans LeadTracker : formulaire par site, activation capture, statut explicite de campagne, provenance CPL et consultation des leads historiques.
- Bouton de rapprochement **avec consentement explicite** pour les soumissions Elementor déjà présentes dans LeadTracker mais encore sans campagne ; matching strict client/domaine/formulaire, zéro déplacement intercampagne, historique conservé.
- Destination Capturia « Google » visible comme projet de transfert, clé API sauvegardée chiffrée via Core, contrôle manuel en **lecture seule** ; le transfert sortant n'est pas activé avant la validation réelle du contrat API écrit et du tag.
- Garde contre l'activation d'une campagne archivée/non publiée ou d'un client désactivé ; logs Core AWM, actions POST nonce/capability/owner, fuite inter-site évitée.
- VMV-NAT #2636 de Vendre Maison Vite : **aucune modification automatique des données de production**, test terrain à confirmer ; retour du site historique Elementor nécessitera une source indépendante si les leads n'ont jamais atteint LeadTracker.

## 1.11.50 — Gestion par type de source CPL — 2026-10-10
- SEO n applique plus aucun pourcentage de frais de gestion : le coût SEO mensuel entre directement dans le CPL.
- Autre propose explicitement « Frais de gestion : Non / Oui ».
- Si Oui, le stagiaire choisit un pourcentage ou un montant fixe mensuel.
- L harmonisation historique applique coût + règle de gestion choisie sur tous les mois et crée les mois manquants.
- Le barème AWM 50/40/30/20/15 % est désormais réservé aux campagnes Google Ads et ne peut plus écraser SEO/Autre.
- Les calculs dashboard, campagne, client et historique tiennent compte des frais fixes sans les convertir artificiellement en pourcentage.

## 1.11.49 — Sources CPL Google Ads / SEO / Autre — 2026-10-10
- Chaque campagne choisit maintenant explicitement Google Ads, SEO ou Autre comme source de coût.
- SEO/Autre acceptent un montant mensuel fixe et un premier mois, puis harmonisent tout l historique en un clic.
- La mise à jour globale sait traiter automatiquement les sources API et les sources fixes.
- Les coûts annexes existants sont préservés pendant l harmonisation.

## 1.11.48 — Historique Google Ads sans dates de campagne — 2026-10-10
- Corrige l erreur terrain `UNRECOGNIZED_FIELD` sur `campaign.start_date` / `campaign.end_date` : LeadTracker ne dépend plus de ces champs pour trouver le début de l historique.
- Vérifie seulement que les campagnes Google Ads cochées existent et sont accessibles, puis lit directement toute la fenêtre mensuelle Google Ads disponible avec `segments.month`.
- Détermine le premier mois réel à partir des lignes mensuelles retournées par Google Ads et ne crée/corrige aucun mois antérieur à cette première observation.
- Conserve les lignes CPL plus anciennes que la première donnée Google Ads trouvée au lieu de les transformer artificiellement en mois à 0 $.
- Le catalogue global ne considère plus un ancien taux 7 % comme preuve suffisante qu une campagne doit être câblée à Google Ads; les campagnes `GADS`/Google Ads ou déjà reliées restent détectées.
- Ajoute un compteur interne des historiques 7 % non classifiés pour diagnostic, sans les afficher comme erreurs au stagiaire.

## 1.11.47 — Historique Google Ads résilient et CPL lisible — 2026-10-10
- Remplace la récupération historique longue par une lecture interne découpée par année à granularité `segments.month`; une seule action utilisateur continue de récupérer toutes les années et tous les mois disponibles.
- Si Google Ads refuse une tranche annuelle, LeadTracker reprend automatiquement mois par mois afin d isoler le mois fautif sans demander une intervention manuelle.
- Les erreurs Google Ads analysent maintenant les détails `GoogleAdsFailure` afin d afficher le vrai code/message et le chemin du champ, plutôt que le seul message générique `Request contains an invalid argument`.
- Le catalogue global distingue désormais les CPL Google Ads réellement à configurer des autres campagnes qui ne sont simplement pas concernées par Google Ads.
- Les métadonnées de synchronisation exposent le nombre de tranches annuelles, les mois relus en repli et les request-id utiles au diagnostic.

## 1.11.46 — Synchronisation globale Google Ads → tous les CPL — 2026-10-10
- Ajoute une opération globale en un clic qui parcourt toutes les campagnes CPL câblées à Google Ads et récupère, campagne par campagne, toutes les années et tous les mois mensuels encore disponibles.
- Chaque CPL conserve son propre câblage multi-campagnes; les coûts des campagnes Google Ads cochées sont additionnés mois par mois avant réconciliation.
- Après une récupération Google Ads complète sans erreur, applique le barème AWM officiel à toutes les lignes CPL de la base : 50 % / 40 % / 30 % / 20 % / 15 %.
- Le barème global supprime les anciens verrous manuels sur le taux de gestion, mais ne touche jamais au rabais, au réceptionniste, aux autres coûts ni au PPC sécurisé.
- Les investissements entre 0,01 $ et 99,99 $ restent signalés À vérifier puisqu aucun barème AWM n est défini sous 100 $.
- La file globale est exécutée séquentiellement côté interface afin d éviter une requête PHP unique trop longue; une erreur Google Ads n arrête pas les autres campagnes, mais bloque le recalcul global final pour ne pas recalculer un CPL sur une dépense périmée.

## 1.11.45 — Google Ads historique mensuel automatique — 2026-10-09
- Corrige l erreur terrain `Request contains an invalid argument` lors d un audit historique couvrant plusieurs années.
- Les séries historiques utilisent maintenant `segments.month` au lieu de `segments.date`, ce qui évite la limite de granularité quotidienne des longues périodes.
- Un seul audit récupère automatiquement tous les mois disponibles, additionne toutes les campagnes Google Ads cochées et corrige les lignes CPL sans lancer chaque mois manuellement.
- Si le début de campagne dépasse la rétention mensuelle Google Ads, LeadTracker conserve les mois plus anciens sans les écraser et signale la période réellement vérifiable.
- Rabais, réceptionniste, autres coûts, PPC sécurisé et logique de gestion AWM restent inchangés.

## 1.11.44 — Audit historique Google Ads mois par mois — 2026-10-09
- Ajoute un audit autoritaire de l investissement Google Ads depuis le début des campagnes Google Ads cochées jusqu au mois actuel.
- Récupère la série mensuelle Google Ads en une seule lecture agrégée par `segments.month`, y compris pour plusieurs campagnes affectées au même CPL.
- Compare chaque mois avec l historique CPL; remplace automatiquement tout investissement différent et recalcule le barème AWM 50/40/30/20/15 %.
- L audit explicite peut corriger un investissement anciennement marqué manuel/legacy; rabais, réceptionniste, autres coûts et PPC sécurisé restent inchangés.
- Les mois absents sont créés afin d obtenir une chronologie continue depuis le début Google Ads.
- Sous 100 $ (hors zéro), l investissement est corrigé mais le taux de gestion reste à vérifier car aucune règle AWM n est définie.
- Les lignes antérieures à la date de début des campagnes Google Ads actuellement cochées sont conservées et exclues de l audit.

## 1.11.43 — Google Ads multi-campagnes pour un CPL — 2026-10-09
- Le moteur Google Ads accepte maintenant une liste de campagnes pour une même campagne LeadTracker/CPL.
- Ajoute `_callink_google_ads_campaign_ids` avec repli transparent sur l ancien `_callink_google_ads_campaign_id`.
- `fetch_monthly_spend()` interroge toutes les campagnes sélectionnées avec `campaign.id IN (...)` et additionne leurs `metrics.cost_micros`.
- La synchronisation et le backfill historique 7 % utilisent la même sélection multi-campagnes.
- Les métadonnées de provenance CPL conservent à la fois le premier ID legacy et la liste complète des IDs.

## 1.11.42 — moteur de recherche du câblage — 2026-10-08
- Ajoute une recherche instantanée sur campagne, client, domaine, formulaire, numéro, source Capturia, CRM Client AWM et état.
- Recherche multi-termes insensible aux accents et sans rechargement de page.
- Ajoute les filtres Tous / Fonctionnels / À vérifier avec compteurs.
- Ajoute compteur de résultats, état vide, effacement rapide et raccourci clavier `/`.
- Aucun changement aux données, au CPL, à Capturia, à Twilio ni aux identifiants techniques `callink_*`.

## 1.11.41 — LeadTracker AWM, câblage visuel et confidentialité locale — 2026-10-07
- Le nom produit visible passe de CallTracker AWM à **LeadTracker AWM** sans renommer les identifiants techniques `callink_*` ni le dossier `awm-calltracker`.
- Ajoute **Câblage des leads**, une vue visuelle Entrées → Attribution → Destinations par campagne.
- Affiche les formulaires Elementor / Gravity Forms / Contact Form 7, les numéros, Capturia, LeadTracker et CRM Client AWM dans le même parcours.
- Le endpoint formulaire accepte `privacy_mode=local_mirror_v1`: nom, courriel et téléphone bruts ne sont pas conservés au centre dans ce mode.
- Ajoute `phone_hash` à l historique formulaires pour conserver la déduplication CPL sans téléphone en clair.
- La déduplication Capturia sait comparer les empreintes téléphone des leads locaux privés aux leads Capturia.
- Les clients sans CRM Client AWM conservent le transport historique afin d éviter une migration silencieuse de la flotte.

## 1.11.40 — Capturia : clé validée, heures cohérentes et CPL sans doublon — 2026-10-06
- Le panneau Capturia affiche maintenant **Clé validée** dès que `tags:read` et `contacts:read` sont prouvés par des synchronisations réussies, même si le preset `/me` n’a pas encore été analysé.
- Une lecture réussie de `/tags` et `/contacts` mémorise explicitement ces capacités afin que le diagnostic ne reste plus bloqué sur « À analyser » après un import réel.
- La date de **Réconciliation tag**, stockée en UTC pour la cohérence interne, est convertie dans le fuseau WordPress au rendu afin d’être alignée avec les autres heures du panneau.
- Le dénominateur CPL déduplique maintenant Capturia contre les formulaires AWM de la même campagne : même courriel ou téléphone normalisé, dans une fenêtre de 24 h, avec appariement un-à-un.
- Les doublons ne sont jamais supprimés de l’historique; ils sont seulement exclus du décompte CPL Capturia. Le panneau affiche **Doublons AWM exclus** pour rendre la règle visible.
- Les `email_hash` des anciens `legacy_email` Laravel ne sont pas utilisés comme preuve d’identité, car ils peuvent représenter le message et non le prospect; le téléphone reste utilisable lorsqu’il est disponible.
- La Source Capturia, son UUID, l’import historique, le pipeline et le rapprochement CRM #57 → #275 restent inchangés.

## 1.11.39 — Capturia : consolidation du dossier CRM actif — 2026-10-06
- Corrige le cas terrain où la campagne VMV était encore liée au client WP historique #57 alors que CRM AWM affiche le dossier opérationnel Olivier Lepage #275 comme Actif.
- La résolution Capturia ne considère plus `_callink_legacy_user_id` comme preuve suffisante lorsqu'il pointe vers un dossier inactif ou archivé.
- Le client legacy fournit maintenant nom, courriel, entreprise et téléphone comme preuves d'identité; CallTracker recherche le dossier CRM actif correspondant.
- Un dossier CRM actif unique est préféré lorsqu'il correspond fortement à la même identité réelle (courriel, téléphone, ou nom + entreprise). En cas d'ambiguïté entre plusieurs dossiers actifs, le connecteur reste prudent et ne choisit pas arbitrairement.
- Le diagnostic distingue maintenant `Campagne WP`, `legacy`, `Client lié` et `CRM`, et affiche les preuves d'identité utilisées.
- Aucun changement Capturia API : la source sélectionnée et `/v1/contacts?tag=<UUID>` restent inchangés.

## 1.11.38 — résolution canonique du client Capturia — 2026-10-06
- Corrige un second faux « client inactif » : un identifiant legacy/WHMCS stocké dans la campagne pouvait être interprété comme un ID utilisateur WordPress avant la lecture du statut CRM.
- Pour les campagnes historiques, `_callink_legacy_campaign_id` est maintenant résolu via `data/callink-legacy-data.json`, puis vers le client CRM canonique par `_callink_legacy_user_id` ou l’adresse courriel legacy exacte.
- Les campagnes modernes continuent d’utiliser directement leur ID client WordPress canonique.
- Les IDs WHMCS/legacy bruts sont normalisés uniquement lorsqu’un seul client CRM canonique correspond exactement.
- Capturia n’appelle plus `canonical_client_status()` avec un identifiant non canonique.
- Les leads Capturia importés utilisent aussi l’ID CRM canonique résolu.
- Le diagnostic affiche `Campagne #… → CRM #…` et distingue un vrai statut Inactif d’un simple lien client incohérent.
- Aucun changement de schéma et aucune réattribution silencieuse de campagne : la normalisation est utilisée par le connecteur Capturia sans réécrire les autres historiques.

## 1.11.37 — republication forcée du correctif Capturia — 2026-10-06
- Republie sous un numéro strictement supérieur le correctif Capturia livré en 1.11.36 afin d’éviter qu’un ancien build portant déjà `1.11.36` soit considéré à tort comme courant.
- Conserve CRM AWM comme unique autorité du statut client pour **Récupérer les leads**.
- Conserve le menu **Source Capturia**, le UUID interne de la source et l’import ciblé `/contacts?tag=<UUID>`.
- Aucun changement de schéma de données; le but est de garantir le déploiement effectif du bon build sur Alliance.

## 1.11.36 — 2026-10-06
- Corrige le faux blocage **« client inactif »** observé pendant **Récupérer les leads** Capturia.
- Capturia utilise désormais `CallLink_CRM::canonical_client_status()` / `canonical_client_is_active()` comme autorité de cycle de vie, exactement comme les autres fonctions opérationnelles AWM.
- Supprime du garde Capturia l’usage de `AWM_Core_Access::is_approved()` et du vieux `_callink_status=disabled` : l’accès portail/Core n’est pas le statut CRM du client.
- Ajoute un repli compatible sur `_callink_crm_account_status`, `_callink_manual_inactive` et l’état WHMCS legacy uniquement si la classe CRM n’est pas encore chargée.
- Ajoute **Statut client CRM** dans le diagnostic Capturia et précise qu’une suspension réelle vient de CRM AWM.
- Les sources Capturia, UUID, clé chiffrée, import de contacts, pagination, CPL et pipeline restent inchangés.

## 1.11.35 — 2026-10-05
- Remplace la saisie technique du tag Capturia par un vrai menu **Source Capturia** alimenté par `GET /v1/tags`.
- Le menu conserve uniquement les tags de catégorie `source` et les tags de campagne dont `system_key` commence par `campaign:`; les campagnes sont regroupées en premier.
- Ajoute l’action **Synchroniser les sources** : CallTracker recharge la liste depuis Capturia, conserve le UUID en interne et affiche le nom lisible à l’administrateur.
- **Récupérer les leads** utilise ensuite `GET /v1/contacts?tag=<UUID>` et exige une source sélectionnée pour les nouvelles configurations afin d’éviter l’import accidentel de tout le compte.
- Permissions minimales documentées : `tags:read` + `contacts:read`. La clé API reste chiffrée dans Core AWM et n’est jamais réaffichée.
- Une nouvelle clé Capturia purge aussi le cache de sources de l’ancien tenant afin de ne jamais proposer une source d’un autre compte.
- Les anciennes configurations explicitement confirmées « tous les contacts » restent tolérées côté moteur pour compatibilité, mais ne sont plus proposées dans le nouveau parcours.

## 1.11.34 — 2026-10-05
- Corrige la règle métier du backfill 7 % : **7 % signifie valeur par défaut/legacy à remplacer**, pas valeur manuelle à protéger.
- Pour chaque mois à 7 %, CallTracker relit le vrai investissement depuis Google Ads, remplace l'investissement historique, puis applique le barème AWM 50/40/30/20/15 %.
- Les verrous/provenances manuels hérités d'une migration sont ignorés uniquement pour ces lignes à 7 %; réceptionniste, autres frais, rabais et PPC sécurisé sont conservés.
- Les investissements Google Ads sous 100 $ sont laissés intacts et signalés À vérifier, faute de règle de gestion définie sous 100 $.

## 1.11.33 — 2026-10-05
- Corrige le backfill historique : le taux exact de 7 % est désormais le marqueur de correction, sans dépendre de `source=legacy` ou `legacy_imported`.
- Les taux explicitement marqués manuels restent protégés; les investissements manuels continuent de primer sur Google Ads.

## 1.11.32 — 2026-10-05
- Ajoute la provenance par champ CPL, protège les saisies manuelles et corrige les lignes historiques à 7 % avec le coût réel Google Ads et le barème AWM officiel.
- Une différence Google Ads sur un investissement manuel devient une proposition automatique visible, jamais un écrasement silencieux.

## 1.11.31 — CPL complet et automatisé — 2026-10-04
- Ajoute un état de complétude mensuel du CPL : **Complet**, **Complet · 0 lead** ou **À compléter**.
- Le diagnostic regroupe investissement, source/devise, fraîcheur Google Ads, barème de gestion, rabais, réceptionniste, autres coûts, appels entrants, formulaires AWM, Capturia et CPL final.
- Ajoute des paramètres mensuels par campagne pour **rabais**, **réceptionniste** et **autres coûts**, applicables automatiquement aux nouvelles lignes créées par Google Ads.
- Une valeur à `0` peut maintenant être explicitement confirmée; elle n'est plus confondue avec un champ simplement oublié.
- Corrige la provenance : modifier uniquement réceptionniste/autres/rabais ne transforme plus une ligne Google Ads en ligne manuelle tant que l'investissement reste inchangé.
- Un changement manuel de l'investissement devient explicitement `manual_override` et le barème de gestion est recalculé.
- Les synchronisations Google Ads fusionnent leurs métadonnées au lieu d'effacer la confirmation des coûts annexes.
- Ajoute une synchronisation Google Ads complète en arrière-plan pour toutes les campagnes associées, avec progression campagne par campagne et traitement accéléré par petits lots.
- Conserve les périodes courante et précédente comme fenêtres automatiques de coût Google Ads; les mois historiques restent lisibles sans être déclarés périmés.
- Aucun changement au dénominateur CPL : appels entrants + formulaires AWM + leads Capturia explicitement inclus.

## 1.11.30 — correctif UX des actions groupées — 2026-10-04
- Corrige le panneau **Modification groupée** natif WordPress qui pouvait encore apparaître et être comprimé dans une colonne étroite par le tableau métier CallTracker.
- Désactive côté PHP les actions groupées natives du CPT `callink_campaign` afin qu elles ne puissent plus contourner le parcours métier sécurisé.
- Retire défensivement du DOM la zone native `.bulkactions` et la ligne `#bulk-edit` si un thème ou une extension WordPress les réinjecte.
- Déplace le bouton **Actions groupées** CallTracker directement dans la barre Recherche / filtres, à l emplacement attendu par l utilisateur.
- Rend le panneau CallTracker hors du tableau, pleine largeur, `box-sizing:border-box`, sans héritage de largeur de colonne ni scroll interne étroit.
- Conserve sans changement le moteur 1.11.29 : aperçu serveur, permission `calltracker/approve`, nonce, token à usage unique, empreinte d état, verrous et journalisation.
- Aucun changement Twilio, routage, schéma SQL, historique, CPL ou données de campagne.

## 1.11.29 — actions groupées guidées dans Campagnes — 2026-10-04
- Ajoute un bouton **Actions groupées** dans CallTracker AWM → Campagnes, activé seulement lorsqu’au moins une campagne est sélectionnée.
- Ajoute les actions courantes **Activer**, **Mettre en pause** et **Réattribuer** avec aperçu serveur avant écriture.
- Réutilise le moteur sécurisé `CallLink_Campaign_Bulk_Actions` existant : nonce, permission `calltracker/approve`, aperçu à usage unique, empreinte d’état, verrous concurrents et journal Core.
- Les actions sensibles **Archiver**, **Corbeille**, **Libérer Twilio** et **Supprimer définitivement** sont séparées dans une zone dédiée et conservent leur phrase de confirmation exacte.
- Les actions Activer / Pause sont idempotentes et ne touchent ni aux numéros Twilio, ni aux historiques, ni au routage. Une campagne archivée ne peut pas être réactivée par lot sans restauration explicite.
- La réattribution conserve le comportement existant : campagne, numéro, appels et formulaires suivent le client cible après validation serveur.
- Le panneau affiche avant exécution le nombre de campagnes, les historiques concernés, les numéros conservés/libérés, les avertissements et les blocages.
- La liste native WordPress d’actions en masse est masquée sur cette vue afin de garder un seul parcours métier guidé.
- Validation terrain 1.11.28 confirmée par l’exploitation : tri serveur, Historique total et vues technicien sont considérés fonctionnels.

## 1.11.28 — tri métier serveur + vues technicien — 2026-10-04
- Rend **Leads 30 j**, **Historique total** et **CPL** triables côté serveur sur l ensemble des campagnes, avec pagination conservée.
- Le tri Leads 30 j utilise appels entrants + formulaires des 30 derniers jours; Historique total utilise tous les appels + formulaires rattachés.
- Le tri CPL utilise le coût du mois courant et le volume de leads du mois, y compris la règle Capturia de la campagne.
- Ajoute les vues technicien **Toutes**, **À vérifier**, **Sans client** et **Sans numéro**.
- Mémorise la vue par utilisateur et la conserve pendant recherche, filtres et pagination.
- **À vérifier** regroupe erreurs de synchronisation, campagnes sans client et campagnes sans numéro principal.
- Aucun changement de schéma SQL, Twilio, routage, migration historique ou données réintégrées.

## 1.11.27 — historique total visible dans Campagnes — 2026-10-04
- Remplace la colonne redondante **Appels 30 j** par **Historique total** dans la liste Campagnes, tout en conservant **Leads 30 j** pour la lecture récente.
- Affiche pour chaque campagne le total cumulé avec le détail **appels + formulaires** afin que les données réintégrées plus anciennes que 30 jours restent immédiatement visibles.
- Ajoute dans le panneau Détails deux cartes distinctes : **Performance 30 jours** et **Historique total**.
- Calcule les métriques 30 jours et les totaux historiques dans les mêmes requêtes groupées par page afin d éviter des requêtes par campagne.
- Utilise l activité historique réelle comme dernière activité lorsqu aucune donnée récente n existe.
- Aucun changement de schéma BD, import, routage Twilio, CPL ou formulaires; les 214 appels historiques restants restent un écart connu non bloquant.

## 1.11.26 — réparation des formulaires historiques — 2026-10-04
- Corrige les formulaires Laravel où `from_email` contenait l’adresse technique du site (`no-reply@...`, `email@...`) au lieu du courriel réel du prospect.
- Extrait du contenu historique le vrai **nom**, **courriel**, **téléphone** et la **page source** lorsque ces données sont présentes.
- Utilise `web_form_capture_url` de la campagne legacy comme repli pour la page source lorsque l’ancien courriel ne contient pas `URL de la page`.
- Le dashboard applique l’extraction à l’affichage immédiatement, même avant la réparation persistante de la base.
- Ajoute dans Migration une réparation ciblée des **44 712 formulaires historiques**, par lots de 100, reprenable et sans retoucher les appels/Twilio.
- Préserve l’expéditeur technique original dans le payload interne `_legacy_sender_email` sans l’afficher comme donnée du prospect.
- Exclut les campagnes en corbeille du mapping actif lors des prochaines réconciliations; leur historique reste archivé par `legacy_campaign_id`.
- Corrige l’état final de migration : une exécution terminée avec erreurs n’est plus affichée « Prête à lancer » mais « Terminée avec N erreur(s) ».
- Validation hors ligne de l’extracteur sur les 44 712 formulaires : 40 105 courriels clients, 38 648 téléphones et 36 461 pages sources récupérables avec les règles prudentes.

## 1.11.25 — démarrage réellement instantané + lots courts — 2026-10-03
- Corrige le cas terrain où **Préparation…** s affichait mais la première requête serveur ne revenait toujours pas.
- Le clic de démarrage ne parcourt plus les 115 fichiers, ne compte plus les tables historiques et n énumère plus tous les tenants : il valide uniquement les trois petits manifestes puis crée la session.
- Le navigateur reçoit un accusé de démarrage avant tout travail lourd; le premier fichier est ensuite vérifié par SHA-256 dans la requête de lot.
- Réduit le lot d écriture de 500 à **100 lignes** pour rester sous les limites PHP/HTTP du serveur et rendre la progression visible.
- Optimise les cartes utilisateurs/campagnes par requêtes SQL groupées au lieu d une série de lectures de métadonnées WordPress.
- Les réponses intermédiaires n exécutent plus de `COUNT(*)` sur les tables après chaque lot; les compteurs exacts sont recalculés à la fin ou au rechargement.
- Ajoute un timeout navigateur explicite : en cas de serveur bloqué, l interface affiche une erreur et le curseur reste reprenable.
- Conserve SHA-256 avant écriture de chaque fichier source, déduplication, rattachement tenant et enrichissements existants.

## 1.11.24 — démarrage immédiat de la réintégration — 2026-10-03
- Corrige le bouton **Démarrer la réintégration** qui pouvait sembler figé pendant que 115 fichiers historiques étaient relus et hachés avant le premier retour AJAX.
- Remplace ce pré-scan lourd par un précontrôle rapide : cohérence des manifestes, présence/taille des 115 fichiers, totaux attendus et propriétaires legacy WordPress.
- Conserve la sécurité SHA-256 : chaque fichier source est vérifié intégralement juste avant le lot qui l importe.
- Affiche immédiatement **Préparation…** au clic puis la progression **Lot source X / 115**, appels, formulaires, lignes traitées et erreurs.
- La migration reste idempotente, reprenable, par lots de 500 et ne touche pas au routage Twilio, aux numéros, aux campagnes ou au CPL.

## 1.11.23 — réintégration historique contrôlée — 2026-10-02
- Ajoute dans **Validation et santé → Rapprochement Laravel → WordPress** un assistant de réintégration pour les **69 306 appels** et **44 712 formulaires** assignés de l’export historique.
- Vérifie avant démarrage les 115 lots historiques par SHA-256 et nombre exact de lignes; refuse l’import si le paquet ne correspond plus à l’export source.
- Importe par lots de 500 avec curseur persistant : fermer/recharger la page ne recommence pas la migration et aucune opération longue n’est nécessaire dans une seule requête.
- Rend la réintégration idempotente grâce aux `legacy_id` et `submission_uid`; les relances mettent à jour/réconcilient sans créer de doublons.
- Le propriétaire WordPress actuel de la campagne reste la frontière de tenant; à défaut, le propriétaire de la campagne dans l’export Laravel sert de repli, puis le client de la ligne source.
- Conserve les enrichissements déjà présents dans WordPress : Recording SID/URL/durée, écoute, child Call SID, payload structuré, téléphone/page de formulaire et autres données ajoutées après le premier import.
- Permet de conserver l’historique d’une campagne qui n’a plus de fiche active : `campaign_post_id=0`, `legacy_campaign_id` conservé et propriétaire client toujours rattaché.
- Journalise préparation, fin de lot, erreurs et clôture dans Core AWM; expose insertions, mises à jour, inchangés, erreurs, réattributions tenant et archives sans campagne active.
- Ne touche ni au routage Twilio, ni aux numéros, ni aux campagnes, ni au CPL pendant cette réintégration historique.
- Corrige aussi le blocage critique détecté par l audit 4.5.347 : ajoute `upload_admin_file()` et `save_bytes()` pour que le wizard Hub puisse réellement téléverser/remplacer les MP3 disclosure/publicité dans le stockage privé CallTracker.

## 1.11.22 — lecteur recordings Twilio / HTTP Range — 2026-10-02
- Corrige le lecteur qui restait à `0:00 / 0:00` malgré un appel et un Recording SID valides.
- Suit jusqu à 5 redirections du média Twilio et conserve le téléchargement côté serveur AWM.
- Ajoute le support des plages HTTP `bytes=start-end` avec réponses 206/416 conformes pour Chrome et les lecteurs HTML5.
- Passe les lecteurs en `preload=metadata` pour charger la durée réelle avant lecture.
- Ajoute un état visuel de lecture (chargement, prêt + durée, lenteur, erreur) sans exposer Twilio au navigateur.
- Aucun changement de schéma BD, routage, attribution d appels, formulaires ou CPL.

## 1.11.21 — synchronisation manuelle des données — 2026-10-02
- Ajoute **Synchroniser** sur chaque carte campagne et **Synchroniser le client** au-dessus de ses campagnes.
- Importe/réconcilie les appels Twilio du numéro suivi pour la période affichée, en conservant le vrai timestamp, statut et durée.
- Rattache les appels locaux au bon `campaign_post_id` par `legacy_campaign_id` puis, lorsque le numéro est unique, par numéro suivi normalisé.
- Rattache les formulaires orphelins au mapping exact site + source + identifiant et actualise les inventaires Hub Client/Connector des sites concernés.
- Affiche un retour de synchronisation avec appels importés/mis à jour/rattachés, formulaires rattachés et sites actualisés, puis recalcule automatiquement les KPI.
- La synchronisation client traite uniquement les campagnes du client ouvert, séquentiellement; aucune synchronisation globale de flotte n est lancée.
- La réconciliation des appels locaux s exécute avant l import Twilio afin de réparer les rattachements même si les identifiants Twilio sont temporairement indisponibles.

## 1.11.20 — correctifs dashboard terrain — 2026-10-02
- Le détail Appels expose le lecteur sécurisé dès qu un Call SID Twilio est disponible, même sans `recording_sid` local.
- À la première lecture, CallTracker cherche les recordings Twilio par Child Call SID puis Call SID, choisit le recording valide, persiste son SID/durée et sert le MP3 côté serveur.
- Le détail Formulaires affiche tous les champs du payload directement : contact, coordonnées, message, champs personnalisés, UTM et métadonnées utiles.
- Les anciens formulaires e-mail affichent également le contenu nettoyé complet lorsque nécessaire.
- Le dashboard est déclaré comme écran CallTracker dans Core 4.5.272 afin d utiliser le header CallTracker AWM au lieu du header Hub.

# 1.11.19 - 2026-10-02

## Ajouté
- Tableau de bord CallTracker centré sur le client : Client -> Campagnes -> Sites/domaines -> Appels/Formulaires.
- 8 KPI compacts et responsive : clients actifs, campagnes actives, appels entrants, formulaires, leads, répondus, manqués, CPL moyen.
- Filtres par client, campagne et période, plus recherche rapide locale.
- Dépliage par client et cartes campagne avec sites exacts, numéro, formulaires configurés, performance et CPL.
- Panneau Appels avec lecture MP3 sécurisée via le serveur AWM, sans exposer les identifiants Twilio.
- Panneau Formulaires avec moteur, identifiant, contact, page et contenu des soumissions.
- Raccourci Tableau de bord ajouté à l’écran Campagnes existant.

## Compatibilité
- Les tables `callink_calls`, `callink_forms`, `callink_route_attempts`, le CPT `callink_campaign` et le moteur CPL restent inchangés.
- Aucun schéma de base de données supplémentaire.

# 1.11.18 — diagnostic Elementor dans l'assistant formulaires — 2026-10-02
- Conserve et affiche le diagnostic `elementor_scan` remonté par Hub Client.
- Après synchronisation d'un site sans formulaire détecté, indique si Elementor Pro est actif et combien de documents Elementor ont réellement été analysés.
- Le bouton **Synchroniser les formulaires** reste ciblé sur un seul WordPress et ne déclenche aucune rafale flotte.

# 1.11.17 — assistant site → synchroniser → choisir — 2026-10-01
- Nouveau parcours en 3 étapes : choisir le WordPress, synchroniser ses formulaires, sélectionner plusieurs formulaires puis enregistrer.
- Le bouton « Synchroniser les formulaires » cible uniquement le site choisi et réutilise les protections anti-rafale Core.
- Ajoute Contact Form 7 comme troisième moteur natif aux côtés de Gravity Forms et Elementor Pro Forms.
- Les associations restent multi-sites et multi-formulaires; racine et /region restent deux WordPress distincts.
- La saisie manuelle reste un secours, pas le parcours principal.

# 1.11.16 — sauvegarde fiable + détection explicite — 2026-10-01
- Corrige la persistance des lignes multi-formulaires avec un payload JSON canonique par ligne; les tableaux historiques restent pris en charge en repli.
- Ajoute un bouton local « Enregistrer les formulaires » et bloque uniquement les lignes incomplètes/doublons avant soumission.
- Corrige le champ de message de succès qui lisait une ancienne clé POST.
- Affiche les sites Connector actifs même si leur premier inventaire formulaires n est pas encore revenu.
- Ajoute « Actualiser la détection » : Core interroge les sites séquentiellement, sans rafale, puis recharge la liste.

# 1.11.15 — UX formulaires détectés multi-sites — 2026-10-01
- CallTracker affiche un parcours 1. Site WordPress → 2. Moteur → 3. Formulaire avec choix détectés automatiquement.
- Une campagne accepte plusieurs WordPress et plusieurs formulaires; les chemins comme /region restent des sites distincts.
- Ajoute un résumé Sites/Formulaires/Gravity/Elementor et une détection visuelle des doublons avant sauvegarde.
- La saisie manuelle reste disponible comme secours si l inventaire du site n est pas encore remonté.
- L inventaire des formulaires est stocké par site Connector et n ajoute aucune requête réseau dédiée : il voyage avec l inventaire Hub Client existant.

# 1.11.14 — 2026-10-01

- Une campagne peut maintenant couvrir plusieurs installations WordPress/domaines, y compris des WordPress distincts sur le même domaine comme `/` et `/region`.
- Chaque formulaire associé porte désormais son **Site WordPress exact** + sa source + son identifiant; les chemins sont conservés pour distinguer les installations.
- UX du bloc Formulaires réorganisée en lignes `Site WordPress → Source → Formulaire`, avec ajout/retrait sans écraser les autres sites de la campagne.
- Compatibilité conservée avec les mappings historiques sans site explicite (`tous les sites liés`).

# 1.11.13 — 2026-10-01

- Refonte UX du bloc Formulaires : plusieurs formulaires par campagne, mélange Elementor + Gravity Forms, ajout/retrait par ligne.
- Gravity Forms est présenté en premier avec un libellé clair « ID Gravity Forms » et un exemple #1 afin d éviter de laisser Elementor sélectionné par erreur.
- Le mapping central est maintenant une liste dédupliquée; le premier mapping reste publié en compatibilité avec les anciens Hub Client.
- Les options techniques du formulaire AWM intégré sont déplacées dans « Options avancées » pour simplifier le parcours stagiaire.

# 1.11.12 — 2026-10-01

- UX Campagnes Appels / Formulaires.
- Ajoute les onglets Appels, Formulaires et Tout afficher; permet de choisir Elementor Pro ou Gravity Forms directement dans la campagne et publie le mapping au Hub Client.

## 1.11.11 — 2026-09-30
- Accepte la source de conversion `hub_client_gravityforms` provenant de Hub Client 1.14.4.
- Les soumissions Gravity Forms restent associées au client et à la campagne CallTracker par le même contrat sécurisé existant.
- Aucun changement au moteur d appels, au routage ni à l UX Campagnes 1.11.10.

## 1.11.10 — 2026-09-30
- Barre Campagnes desktop verrouillée sur une seule rangée : recherche, action groupée, Appliquer, Client, Statut, Source et Filtrer.
- Suppression des contraintes WordPress qui pouvaient forcer `p.search-box` sur une ligne séparée (`position`, `clear`, largeur).
- Le conteneur `alignleft actions` passe en `display: contents` afin que tous les contrôles partagent le même flex parent.
- Largeurs resserrées progressivement à 1500 px et 1100 px; repli multi-ligne réservé au mobile/tablette étroite.
- Pagination supérieure reste masquée; pagination inférieure inchangée.

## 1.11.9 — 2026-09-30
- Force la barre Campagnes desktop sur une seule ligne : recherche, actions groupées, filtres client/statut/source et boutons restent alignés horizontalement.
- Compresse proprement les largeurs et espacements à 1500 px et raccourcit le bouton de recherche à « Rechercher » sans casser les libellés principaux.
- Retire la pagination WordPress du haut de la liste (compteur + flèches) afin d éliminer le bloc isolé sous les filtres; la pagination du bas reste disponible.
- Conserve un repli responsive sous 1100 px et l empilement mobile existant.
- Aucun changement de données, Twilio, routage, Capturia, Google Ads ou CPL.

# Changelog — CallTracker AWM

## 1.11.8 — 2026-09-30
- Affiche le **nom complet de la campagne** et le **nom complet du client** avec retour à la ligne propre au lieu d'une ellipse trop agressive.
- Supprime la colonne/badge texte de statut afin de libérer de la largeur pour Campagne et Client.
- Remplace le statut par un point unique à côté du nom : **vert = actif**, **jaune = pause**.
- Rend ce point cliquable pour basculer Actif ↔ Pause sans ouvrir la campagne, avec nonce WordPress, `edit_post`, journal AWM et retour visuel immédiat.
- Maintient **CPL** visible en mode compact jusqu'aux très petites largeurs et rend l'en-tête du tableau sticky pour identifier clairement les valeurs `—`.
- Conserve les favicons 1.11.7, le tableau sans overflow horizontal, Twilio, Capturia, Google Ads, routage et formule CPL inchangés.

## 1.11.7 — 2026-09-30
- Supprime le défilement horizontal du tableau Campagnes en desktop : largeur fixe à 100 %, `table-layout: fixed`, colonnes compactes et contenu tronqué proprement plutôt que poussé hors fenêtre.
- Ajoute un mode de densité **Compact / Détaillé** mémorisé par navigateur. Compact devient le choix par défaut sous 1680 px; le mode Blocs reste prioritaire sur mobile.
- Masque progressivement les colonnes secondaires à 1500 / 1280 / 1100 px afin de conserver Campagne, Client, Numéro, Routage, Statut et activité dans la fenêtre sans barre de déplacement en bas.
- Réduit les actions de ligne en largeur intermédiaire; les actions secondaires restent accessibles dans le panneau de détail.
- Remplace la lettre du client par sa **favicon réelle** : favicon manuelle Hub, favicon détectée par le moteur de style, puis `/favicon.ico` du site client en repli. Si aucune image ne charge, une icône de site neutre est affichée, jamais une initiale.
- Conserve Twilio, Capturia, Google Ads, CPL, routage, modèles et données inchangés.

## 1.11.6 — 2026-09-30
- Force les cinq KPI de la page **Campagnes** sur une seule rangée en desktop et laptop.
- Remplace les cassures 3+2 / 2+2+1 par une compression contrôlée puis un défilement horizontal tactile sur petits écrans.
- Réduit et harmonise hauteur, padding et typographie des cartes KPI avec `clamp()` pour conserver la lisibilité à 1366 px / 1080p.
- Réorganise la barre Recherche / filtres / actions / pagination avec une grille responsive puis un empilement propre sur mobile.
- Protège le tableau métier avec une largeur minimale afin d'éviter les retours de ligne excessifs dans Client, Numéro et Routage; le conteneur devient scrollable au besoin.
- Conserve le mode **Blocs**, le détail rapide, les données, le routage Twilio, Capturia, Google Ads et le CPL inchangés.

## 1.11.5 — 2026-09-30
- Refonte complète du listing **Campagnes** en tableau métier professionnel et responsive, sans remplacer le CPT historique ni son éditeur.
- Ajoute les KPI en tête : campagnes actives, clients couverts, leads 30 jours, CPL pondéré du mois courant et alertes de routage/synchronisation.
- Ajoute les colonnes Client associé, Source/type, Numéro principal, Routage/équipe, Statut, Leads 30 j, Appels 30 j, CPL, Dernière activité et actions compactes.
- Ajoute les filtres client, statut et source directement dans la liste Campagnes.
- Ajoute un basculement **Tableau / Blocs** mémorisé par navigateur; le mode Blocs devient automatiquement prioritaire sur petit écran.
- Ajoute un panneau de détail rapide d une campagne avec client, source, numéro, routage et performance 30 jours.
- Conserve les données, le routage Twilio, le calcul CPL, Capturia, Google Ads, les modèles de routage et les URLs d édition existantes.

## 1.11.4 — 2026-09-30
- Ajoute les filtres 7 / 30 / 90 jours aux statistiques de routage de chaque campagne.
- Ajoute un export CSV UTF-8 détaillé avec résumé de campagne et chaque tentative Twilio.
- Prépare le prochain calcul de temps avant réponse sans l inventer : `DialCallDuration` mesure la conversation et ne doit pas être confondu avec le temps de sonnerie.
- Conserve la télémétrie additive introduite en 1.11.3; aucun historique antérieur n est inventé.
- Aucun changement de formule CPL, Capturia, Google Ads, modèles de routage ou chaîne Twilio.

## 1.11.3 — 2026-09-29
- Ajoute une journalisation SQL additive de chaque tentative de routage Twilio séquentiel : étape, destination, statut, durée et appel enfant.
- Ajoute dans **Routage avancé** un tableau **Performance du routage — 30 jours** avec appels routés, taux de réponse, récupération par secours et appels sans réponse.
- Détaille les performances par étape : tentatives, réponses, taux, durée moyenne, sans réponse et occupé.
- Enregistre sur l appel répondu l étape, le libellé et la destination qui ont effectivement décroché.
- Les statistiques commencent à partir de 1.11.3; aucun historique antérieur n est inventé ou recalculé.

## 1.11.2 — 2026-09-29

- Corrige le piège UX observé en production : charger un modèle de routage applique maintenant immédiatement l'équipe à la campagne au lieu d'attendre un enregistrement WordPress séparé.
- Ajoute **Appliquer l'équipe maintenant** pour rendre les modifications manuelles actives sans enregistrer toute la fiche.
- Le simulateur utilise désormais les valeurs actuellement visibles dans le formulaire, même avant sauvegarde, et affiche explicitement les étapes 1 → 2 → 3 avec la condition « si sans réponse ».
- Ajoute un état visuel lorsque des modifications de routage sont présentes dans le formulaire mais pas encore appliquées aux appels réels.
- Journalise l'application immédiate via `calltracker_routing_team_applied_live`.

## 1.11.1 — 2026-09-29
- Ajoute des modèles de routage réutilisables directement dans le bloc « Routage avancé — équipe et simulateur ».
- Un modèle copie jusqu à cinq destinations avec libellé, numéro, priorité, activation et délai de sonnerie; la campagne reste indépendante après chargement.
- Permet d enregistrer, charger et supprimer jusqu à vingt modèles globaux avec permissions CallTracker et nonce WordPress.
- Le routage Twilio séquentiel 1.11.0, le CPL, Capturia, Google Ads et les appels existants restent inchangés.

## 1.11.0 — 2026-09-29

- Ajoute le Lot C phase 2 pour le routage entrant : jusqu à cinq destinations de débordement nommées et priorisées par campagne.
- Chaque destination de secours possède son propre délai de sonnerie de 10 à 60 secondes.
- Étend la route TwiML `routing-next` pour parcourir une chaîne séquentielle par index, tout en conservant la compatibilité avec les callbacks `primary/overflow` de 1.10.x.
- Ajoute un simulateur non destructif dans l éditeur de campagne pour tester une date/heure dans le fuseau de campagne et afficher la route exacte sans contacter Twilio.
- Conserve `_callink_overflow_destination` comme premier secours de compatibilité avec Hub Client et les anciennes campagnes.
- Étend Validation et santé et l empreinte d approbation aux membres de l équipe de débordement.
- Refuse les doublons et les collisions avec les destinations principale et hors-heures avant toute écriture.
- Aucun changement de tables, appels, CPL, Google Ads, Capturia, numéros ou secrets Twilio.

---

## 1.10.9 - Capturia branchement par clé API uniquement - 2026-09-25
- Le parcours ne suppose plus aucun accès au tableau de bord Capturia : l administrateur AWM colle uniquement la clé fournie par le client.
- `GET /v1/me` mémorise le compte détecté, le preset, les scopes et l expiration de la clé sans exposer le secret.
- `GET /v1/contacts?limit=1` devient le test obligatoire : `contacts:read` est le seul droit minimal nécessaire pour calculer des leads/CPL.
- `tags:read` devient recommandé mais non bloquant : si absent, la connexion reste valide et AWM explique précisément la permission manquante.
- L interface affiche les permissions détectées et distingue droits requis (`contacts:read`) des droits recommandés/optionnels (`tags:read`, `pipeline:read`, `bookings:read`).
- Protection anti-surcomptage : sans tag, les contacts ne peuvent pas entrer dans le CPL tant qu un administrateur ne confirme explicitement que tous les contacts accessibles par cette clé appartiennent à la campagne.
- L option d inclusion Capturia dans le CPL est désormais désactivée par défaut sur une nouvelle liaison et exige une attribution sûre.
- Aucune écriture Capturia ajoutée; le connecteur reste GET-only et serveur-à-serveur.

## 1.10.8 - Validation CPL Capturia et pipeline lecture seule - 2026-09-25
- Ajout d une synchronisation optionnelle `GET /v1/pipeline/stages` + `GET /v1/pipeline/deals`, strictement en lecture, après la synchronisation des contacts Capturia.
- Les opportunités sont rattachées uniquement aux `contact_id` déjà importés pour la campagne/tag AWM; les compteurs globaux Capturia ne sont jamais utilisés pour attribuer une campagne.
- Nouvel état local `callink_capturia_state` par campagne/contact : présence du tag + état pipeline courant.
- Réconciliation complète quotidienne du tag Capturia : un contact supprimé ou retiré du tag n est retiré du CPL local qu après un scan complet réussi; aucune purge n est faite sur un scan partiel ou en erreur.
- Le panneau Capturia montre le mois courant : leads importés, leads comptés dans le CPL, opportunités actuelles, valeur pipeline et répartition par étape.
- Le test de connexion vérifie aussi les capacités `pipeline:read` et `bookings:read`; une permission optionnelle absente ne bloque jamais l import des contacts ni le CPL.
- Les rendez-vous restent en diagnostic uniquement tant qu un lien campagne/contact fiable n est pas confirmé dans le payload réel du premier client.
- Aucune écriture n est envoyée à Capturia et la formule CPL reste inchangée.

## 1.10.7 - Capturia lecture seule et CPL - 2026-09-24

- Ajoute une intégration Capturia directement sur les campagnes CallTracker existantes; aucun Hub Client ni plugin AWM n est requis sur la landing page du client.
- Stocke la clé API Capturia chiffrée avec `AWM_Core_Vault`, dans un contexte propre à la campagne, et ne la réaffiche jamais.
- Valide la connexion avec `GET /v1/me`, charge les tags avec `GET /v1/tags` et synchronise les contacts via `GET /v1/contacts` uniquement.
- Permet de filtrer les contacts par tag Capturia afin de rattacher les bonnes statistiques à la bonne campagne AWM.
- Ajoute un import historique progressif puis une synchronisation incrémentale automatique toutes les 15 minutes, avec curseur opaque Capturia, journalisation et conservation du request ID en cas d erreur.
- Enregistre chaque contact avec un `submission_uid` stable et `source=capturia`; les resynchronisations mettent à jour le même lead au lieu de le dupliquer.
- Sépare dans le CPL les formulaires AWM et les leads Capturia; Capturia n est inclus dans le dénominateur que si la campagne l autorise explicitement.
- Suspend la synchronisation Capturia si le client CRM est inactif et conserve les données historiques sans suppression.
- Validation statique possible sans clé réelle; la validation terrain de la portée de la clé et du tag reste à effectuer sur le premier client Capturia.

## 1.10.6 - Refonte UX Google Ads / CPL - 2026-09-21

- Refonte complete de la page **CallTracker AWM -> Google Ads** pour suivre le shell visuel AWM en Light et Dark.
- Ajoute un en-tete acquisition/CPL avec etats OAuth, MCC et synchronisation visibles immediatement.
- Remplace le rendu WordPress brut des champs par des cartes, champs, boutons, tableaux et etats coherents avec CallTracker.
- Ameliore fortement le responsive mobile/tablette, notamment la liste des MCC et les actions.
- Aucun changement OAuth, API Google Ads, calcul CPL, table SQL ou historique : correctif UX uniquement.

## 1.10.5 - Interface Google Ads restaurée dans CallTracker - 2026-09-21

- Ajoute une page **CallTracker AWM -> Google Ads** directement depuis le module, sans dépendre de Hub AWM -> Réglages.
- Corrige la régression où Hub AWM 4.5.57 masquait l ancien écran `callink-google-ads` alors que le moteur Google Ads 1.10.4 restait actif.
- Permet d enregistrer OAuth Client ID / Secret, les deux MCC ou davantage, puis de connecter Google Ads.
- Ajoute un test de MCC qui liste les comptes clients accessibles avant toute association de campagne.
- Conserve le moteur CPL multi-MCC 1.10.4, l historique, la formule CPL et les synchronisations automatiques.
- Le Developer Token historique reste compatible; depuis le 9 septembre 2026, Google rattache l accès API au projet Google Cloud des identifiants OAuth.

## 1.10.4 - Google Ads CPL multi-MCC automatise - 2026-09-21

- Utilise Google Ads API v25 pour recuperer `metrics.cost_micros` par MCC, compte et campagne.
- Le Developer Token devient facultatif dans le moteur: si un ancien token existe il reste envoye pour compatibilite, sinon l acces repose sur le projet Google Cloud lie aux identifiants OAuth.
- Conserve plusieurs MCC dans une seule integration CallTracker et utilise le bon `login-customer-id` par campagne.
- Ajoute la devise Google Ads, le `request-id`, la source et la fraicheur de synchronisation au CPL.
- Ajoute une synchronisation automatique par petits lots toutes les 15 minutes pour le mois courant et le mois precedent, sans longue requete bloquante.
- Une erreur Google Ads ne remplace jamais un investissement valide par zero; la campagne passe en etat `stale` avec la derniere erreur conservee.
- Etend la table CPL de facon additive avec source, devise, statut, date de synchro et metadonnees de source.
- Le mode manuel et l historique Laravel restent disponibles sans migration destructive.
- Les futurs profils OAuth multiples restent prevus seulement si les deux MCC exigent des identites Google differentes.

## 1.10.3 — Pulse v2 routage — 2026-09-12

- Le score Health CallTracker pénalise uniquement les erreurs de synchronisation/routage connues.
- Les campagnes et Twilio restent non modifiés automatiquement; le score sert au triage.

## 1.10.2 — Pulse opérationnel transversal — 2026-09-12

- Expose au Core un pulse campagnes actives / brouillons / erreurs de synchronisation routage.
- Le pulse reste strictement descriptif et ne déclenche aucune opération Twilio.

## 1.10.1 — 2026-09-11
- CallTracker respecte désormais le statut opérationnel canonique de CRM AWM.
- Un client inactif n'est plus éligible aux opérations CallTracker, tout en conservant campagnes, appels, enregistrements et historique.
- La réactivation CRM restaure l'éligibilité selon le réglage CallTracker déjà enregistré.

## 1.10.0 — 2026-09-02

- Structure le parcours client **CallTracker → Nouveaux services → Nouveau funnel → Configuration du numéro → Formulaire/Webhook → Routage**.
- Sépare définitivement la commande commerciale de l exécution technique : CRM crée et possède le service Funnel à 10 $/mois; CallTracker prépare la campagne technique.
- Un nouveau funnel commence en état **configuration requise** et n active pas la facturation récurrente tant qu aucun numéro n a été acheté et attribué.
- L achat du numéro réutilise le service CRM et la campagne préparés, revalide la disponibilité Twilio juste avant la transaction puis active le service CRM après succès.
- Un échec Twilio laisse le funnel en configuration pour permettre une nouvelle tentative sans recréer un abonnement; un achat potentiellement accepté mais incomplet est conservé pour vérification afin d éviter un double achat.
- Étend le routage modifiable par Hub Client : destination principale, fuseau, horaires, fermetures, destination hors heures, débordement séquentiel, délai et Message 2.
- Conserve toutes les validations de propriété côté serveur et journalise séparément les modifications effectuées depuis Hub Client.

## 1.9.9 — 2026-09-02

- Ajoute un webhook HTTPS unique et secret pour chaque Funnel CallTracker.
- Active automatiquement la structure de formulaire du funnel après achat du numéro et génère son URL de webhook sans exposer de secret Twilio.
- Accepte les envois POST JSON ou formulaire de plateformes externes et reconnaît les champs courants nom, courriel, téléphone, message et URL de page.
- Ajoute une protection anti-rejeu courte et un identifiant idempotent lorsque la plateforme fournit `submission_id` ou un identifiant de requête.
- Les formulaires reçus sont enregistrés dans l historique CallTracker existant et alimentent immédiatement Leads et CPL du bon funnel.
- Ajoute un test client non destructif qui vérifie campagne, jeton et stockage sans créer de faux lead.
- Conserve le dernier instant de réception par funnel pour faciliter le diagnostic dans Hub Client.

## 1.9.8 — 2026-09-02

- Ajoute la recherche sécurisée de numéros Twilio pour Hub Client sans exposer les identifiants ni les URL d API.
- Permet au client CallTracker autorisé d acheter un numéro et de créer son Funnel directement depuis son Hub.
- Chaque achat crée une campagne CallTracker, attribue le numéro et lie un service CRM Funnel à 10 $/mois.
- Le service est préparé avant l appel Twilio et supprimé automatiquement si aucun achat externe n a eu lieu.
- Si Twilio accepte l achat mais qu une étape locale échoue, la campagne est conservée pour empêcher un double achat et Alliance reçoit un état à vérifier.
- L inventaire des numéros est invalidé après achat afin de refléter immédiatement le nouveau numéro.

## 1.9.7 — 2026-09-02

- Livre la phase 1 du **Lot C — Routage avancé**.
- Ajoute des horaires hebdomadaires par campagne dans le fuseau déjà géré par CallTracker.
- Ajoute les fermetures spéciales / jours fériés au format YYYY-MM-DD.
- Ajoute une destination hors heures facultative; si elle est vide, CallTracker ferme proprement l appel au lieu de transférer vers une mauvaise route.
- Ajoute une destination de débordement séquentielle après non-réponse, occupé ou échec de la première destination.
- Ajoute un délai de sonnerie configurable de 10 à 60 secondes.
- Ajoute un aperçu de la route effective dans Hub : état Ouvert/Fermé, heure locale, destination actuelle et débordement.
- Ajoute la route Core `callink/v1/routing-next` signée par Twilio pour enchaîner le secours sans sonner deux destinations en parallèle.
- Étend Validation et santé : empreinte, horaire, destination hors heures, débordement, délai et tests requis.
- Les équipes, priorités, stratégies multi-tentatives, modèles réutilisables et tests simulés restent dans le Lot C phase 2.

# Changelog — CallTracker AWM

## 1.9.6 — 2026-08-25
- Ajoute la bascule globale de l’ancienne plateforme dans **Validation et santé**.
- Resynchronise par lots tous les numéros des campagnes actives et les numéros encore actifs dans l’export legacy retrouvés localement vers le webhook entrant AWM.
- Reprend également les numéros dont les appels entrants sont désactivés et les numéros actifs legacy retrouvés sur une campagne locale maintenant inactive; AWM garde le webhook puis bloque leur transfert.
- Refuse la finalisation si un numéro actif de l’export legacy ne correspond à aucune campagne locale, afin de ne jamais laisser un numéro oublié sur l’ancienne plateforme.
- Résout les Phone Number SID manquants, retire `VoiceFallbackUrl` et `VoiceApplicationSid`, puis relit Twilio pour confirmer la reprise.
- Ajoute progression, aperçu, erreurs par campagne, reprise sans popup et journal Core.
- Ajoute le verrou **BASCULE AWM** qui transforme Laravel en référence historique et bloque les nouveaux imports migration/CPL.
- Ajoute une réouverture exceptionnelle explicite pour les imports historiques.
- Conserve Lot C Routage avancé comme prochaine implémentation et référence l’accès API Google approuvé pour le futur Lot E CPL/Google Ads.

---

## 1.9.5 — 2026-08-25
- Corrige les campagnes existantes dont le numéro de réception a été modifié : la sauvegarde déclenche maintenant une resynchronisation du webhook entrant Twilio vers AWM.
- Vérifie le Phone Number SID; s'il manque ou ne correspond plus au numéro de campagne, le SID est recherché dans le compte Twilio configuré puis rattaché à la campagne.
- Priorité de destination explicite : numéro de transfert de campagne, puis numéro du client en fallback.
- Une modification du numéro client resynchronise automatiquement les campagnes qui utilisent ce fallback et n'ont pas d'override propre.
- Ajoute un bloc « Routage entrant Twilio » dans l'éditeur avec destination effective, dernière destination synchronisée, date, erreur éventuelle et bouton de resynchronisation manuelle.
- Conserve une empreinte de configuration afin de ne contacter Twilio que lorsqu'un élément critique de routage change.
- Journalise les synchronisations et échecs dans Core AWM sans empêcher l'enregistrement local de la campagne.
- Exige Core AWM 4.5.43.
- Utilise Hub AWM 4.5.15 pour empêcher le Heartbeat WordPress de déclencher le loader plein écran toutes les ~30 secondes dans l’éditeur.

## 1.9.4 — 2026-08-25

- Retire l'autosave WordPress natif de l'éditeur interne `callink_campaign` afin d'éviter le dialogue bloquant « Connexion perdue » et la sauvegarde locale navigateur hors du contrat AWM.
- Conserve Heartbeat pour les verrous/session, mais affiche l'état de connexion directement dans la barre **Enregistrer la campagne**.
- Affiche **Connexion active**, **Hors ligne — reconnexion automatique** ou **Connexion WordPress instable — enregistrement manuel disponible** sans modal navigateur.
- Le bouton d'enregistrement n'est désactivé que lorsque le navigateur est réellement hors ligne; une alerte Heartbeat seule n'empêche pas une tentative manuelle.
- Supprime les notices natives `lost-connection` / stockage local lorsqu'elles sont injectées dans l'éditeur de campagne.
- Exige Core AWM 4.5.42 et Hub AWM 4.5.14 pour l'expérience complète.
- Référence le correctif dans la roadmap sans marquer les validations Twilio terrain comme terminées.

---

## 1.9.3 — 2026-08-25

- Ajoute un registre persistant d idempotence pour les callbacks Twilio de statut et d enregistrement.
- Détecte les rejeux et empêche les doubles écritures sans bloquer les retries légitimes des routes TwiML.
- Empêche les statuts hors ordre de faire régresser un appel grâce à `SequenceNumber` et aux états monotones.
- Ajoute une file de reprise locale courte pour erreurs transitoires, cinq tentatives et un état échec définitif visible dans Validation et santé.
- Évite de rejouer les erreurs 4xx déterministes.
- Normalise appels et formulaires vers un temps UTC canonique et calcule les périodes CPL dans le fuseau de chaque campagne.
- Retire l URL Twilio brute du contrat client et passe la lecture des enregistrements par un proxy sécurisé Core/Hub Client.
- Exige Core AWM 4.5.41; l expérience client complète utilise Hub Client AWM 1.8.7.
- Met à jour roadmap et documentation sans marquer les validations terrain comme terminées.

---

## 1.9.2 — 2026-08-25

- Ajoute le centre **Validation et santé** accessible depuis Hub AWM.
- Compare les compteurs de migration attendus et importés pour clients, campagnes, numéros, appels, formulaires et périodes CPL, en tenant compte des exclusions persistantes.
- Analyse les doublons, orphelins et incohérences de propriétaire afin de faire ressortir les exceptions avant clôture.
- Ajoute un diagnostic par campagne : client, numéro, SID Twilio, affectation, webhook entrant, destination, fuseau horaire, Message 1, Message 2, Dialer, enregistrement et dernière activité.
- Ajoute un parcours de tests guidés pour la configuration, l’appel entrant, la destination, le CPL, le Dialer sortant, l’enregistrement et les messages audio selon les réglages actifs.
- Permet d’approuver une campagne seulement après validation explicite; l’approbation est liée à une empreinte SHA-256 des paramètres critiques et devient périmée si ceux-ci changent.
- Ferme l’exposition client du CPL par défaut : Core et Hub Client n’affichent que les campagnes approuvées, avec un état **CPL en validation** pour les autres.
- Ajoute une clôture de migration signée et réversible après approbation des campagnes actives; la clôture est refusée lorsque des exceptions bloquantes subsistent ou qu’une campagne active reste non approuvée; les campagnes inactives peuvent être revues séparément pour leur CPL historique.
- Remplace les confirmations navigateur natives des principaux flux CallTracker actifs par des confirmations AWM intégrées : inventaire de numéros, achats/réservations, campagnes, imports, CPL, Twilio, Google Ads, audio et historique.
- Journalise les validations, approbations, réouvertures et clôtures dans Core AWM.
- Exige Core AWM 4.5.39, Hub AWM 4.5.13 et Hub Client AWM 1.8.6 pour l’expérience complète.

---

## 1.9.1 — 2026-08-24

- Ajoute un marqueur de résultat explicite pour les opérations natives de campagne : corbeille, restauration, suppression définitive et enregistrement groupé.
- Ces résultats sont consommés par le loader AWM au lieu d’un bandeau WordPress.
- Le mécanisme reste compatible avec l’action native « Annuler » extraite par Hub lorsque WordPress la fournit.
- Aucun changement de tables, métas, routes métier, tombstones, historique ou formule CPL.

---

## 1.9.0 — 2026-08-24

- Corrige définitivement le lien WordPress `Toutes` noir sur noir : `.subsubsub` est stylé directement car WordPress le rend hors de `#posts-filter`.
- Ajoute les réglages par campagne **Enregistrer les appels**, **Dialer côté client** et **Fuseau horaire**.
- Le fuseau proposé provient uniquement de la fiche CRM/WHMCS; aucune recherche d’adresse externe n’est lancée.
- Les appels entrants peuvent demander un enregistrement Twilio conditionnel avec callback Core; les métadonnées d’enregistrement sont synchronisées dans l’historique canonique.
- Les appels sortants restent visibles mais strictement exclus des leads et du CPL.
- La migration réutilise le réglage historique `record_call` pour initialiser le nouveau réglage sans rupture.

## 1.8.1 — 2026-08-24

- Corrige le listing WordPress des campagnes pour qu’il hérite entièrement des couleurs du shell AWM en clair/sombre.
- Rétablit le contraste de « Toutes », filtres, pagination, champs de recherche, tableaux et actions lorsque le thème sombre est changé dynamiquement.
- Remplace les fonds noirs opaques du listing par les surfaces partagées Hub/Core sans modifier les campagnes ni leur historique.

## 1.8.0 — 2026-08-24

- Ajoute le routage entrant par campagne avec **Message 1 — Avertissement** puis **Message 2 — Publicité** avant la redirection.
- Intègre le MP3 d’avertissement Alliance par défaut; Alliance peut le remplacer ou revenir au fichier par défaut.
- Permet au client de téléverser/remplacer/supprimer son Message 2 MP3, de l’activer/désactiver et de modifier son numéro de réception uniquement pour ses campagnes.
- Ajoute le contrôle administratif complet des deux messages et de la destination depuis la fiche client Hub AWM.
- Stocke les MP3 dans un répertoire privé Alliance, limite à 5 Mo, valide la signature MP3 et les sert par une URL Core signée.
- Écrit maintenant les nouveaux appels Twilio entrants et sortants dans `callink_calls` en plus du post type historique; les callbacks mettent à jour statut et durée de façon idempotente.
- Les appels sortants apparaissent dans l’historique comme **Sortant** mais restent strictement exclus des leads et du CPL.
- Conserve la migration Laravel, les identifiants historiques, les exclusions anti-réimportation et les routes existantes.

---

# Changelog — CallTracker AWM

## 1.7.0 — 2026-08-19

- Rafraîchit le lot de migration à partir de l’export Laravel du 19 août 2026.
- Intègre 69 306 appels et 44 712 formulaires attribuables; conserve 17 appels et 2 379 formulaires orphelins hors attribution.
- Utilise le propriétaire canonique de la campagne comme frontière client pour 25 351 appels dont le `client_id` Laravel historique diffère, tout en conservant cet identifiant pour audit.
- Étend l’outil Migration existant aux 3 602 lignes de coûts/CPL et protège les lignes WordPress manuelles.
- Signale les erreurs SQL CPL comme résultat partiel plutôt que comme réussite complète.
- Refuse l’import CPL vers une campagne non publiée, en corbeille, supprimée ou exclue.
- Ajoute le formulaire AWM intégrable par campagne avec défi HMAC, anti-robot, limitation et dédoublonnage.
- Ajoute la réception Connector pour Elementor et autres intégrations locales autorisées.
- Étend `callink_forms` de manière additive aux identifiants de soumission, sources, téléphone, page et empreintes techniques.
- Aligne le nombre de leads sur appels entrants plus formulaires dans l’administration et le portail client.
- Conserve le flux courriel historique comme repli et ne prend pas en charge les fichiers dans cette première version.
- Exige Core AWM 4.5.8; aucune table, route, option, méta ou identité historique n’est supprimée ou renommée.

---

## Historique des versions précédentes

# Changelog — CallTracker AWM

## 1.6.0 — 2026-08-19

### Ajouté
- Service `CallLink_Campaign_Bulk_Actions` pour les aperçus et exécutions groupées de campagnes et réservations locales.
- Actions campagne : archivage, corbeille, libération Twilio, suppression définitive et réattribution cliente.
- Actions inventaire : réservation locale, réattribution et retrait de réservation.
- Aperçu serveur détaillé, phrase de confirmation, jeton à usage unique revendiqué atomiquement, empreinte d’état, verrouillage concurrent, limites de lot et résultats par élément.
- API interne d’inventaire partagée par les parcours unitaires et groupés : normalisation, lecture, écriture et retrait de réservation.

### Sécurité et compatibilité
- Niveau Core `calltracker/approve`, nonce, validation stricte, confirmation sensible à la casse et journalisation pour chaque lot sensible.
- Le client cible d’une réservation est revalidé côté serveur avec la même éligibilité CallTracker que l’interface.
- Inventaire Twilio relu directement lors de l’exécution d’un lot de réservations.
- Exclusion legacy explicitement persistée pour les mises à la corbeille et suppressions personnalisées.
- Appels et formulaires conservés; aucune table, option, route, méta ou identifiant historique renommé ou supprimé.
- Le post type historique `callink_campaign` et le statut technique `publish` restent compatibles et non publics.

### Corrigé
- Les suppressions par changement direct de statut ne peuvent plus contourner la protection anti-réimportation.
- Les actions unitaires et groupées utilisent maintenant la même frontière de validation des réservations.
- Une erreur de nettoyage local après une libération Twilio irréversible est signalée et journalisée sans présenter la libération externe comme annulée.
- La libération Twilio retire désormais la réservation locale depuis une seule frontière partagée par les parcours unitaires et groupés.
- Les lots campagne qui libèrent ou réattribuent un numéro verrouillent aussi la ressource téléphonique afin d’éviter une collision avec un lot de réservations.
- Les corbeilles et suppressions destructives échouent de manière fermée si l’exclusion legacy d’une campagne historique ne peut pas être réellement persistée.
- Les options partagées de réservations, d’exclusions legacy et d’instantanés de suppression utilisent maintenant des écritures sérialisées avec relecture de persistance.
- Après une libération Twilio acceptée, l’état local, les appels entrants, le Dialer et le retrait de réservation sont contrôlés séparément; toute divergence est signalée dans le résultat et le journal Core.
- Une réattribution vérifie le propriétaire enregistré, restaure la réservation concurrente si l’écriture principale échoue et compare le nombre d’appels/formulaires réellement propagés.

---

## 1.5.1 — 2026-08-19
- L’éditeur natif `callink_campaign` n’utilise plus le workflow éditorial WordPress : libellés Campagne, boîte Publier retirée et colonne latérale de publication supprimée.
- Ajout d’une barre AWM « Enregistrer la campagne »; le statut WordPress `publish` reste uniquement un état technique interne de compatibilité.
- Les messages « Article mis à jour » deviennent « Campagne enregistrée » et sont consommés par le loader AWM au lieu d’un bandeau.
- La liste Campagnes masque les vues de statuts éditoriaux WordPress et remplace la colonne Publication par « Dernière modification ».
- La campagne reste explicitement non publique et non exposée au front-end.

## 1.5.0 — 2026-08-19
- Ajout de l’inventaire Twilio à quatre états : **Libre, Réservé, Attribué, À vérifier**.
- Comparaison serveur du compte Twilio Alliance avec toutes les campagnes CallTracker sans exposer les identifiants Twilio au navigateur.
- Détection des doublons de numéro, campagnes locales absentes du compte Twilio, réservations orphelines et numéros encore détenus après corbeille/libération déclarée.
- Affichage du dernier rattachement connu, de la campagne et du client lorsque disponibles.
- Réservation et retrait de réservation protégés par permission CallTracker Modifier, nonce, validation et journal de sécurité Core.
- Cache Twilio court et invalidation automatique après achat ou libération d’un numéro.

## 1.4.1 — 2026-08-18
- Le Dialer accepte maintenant une campagne liée à un alias historique sûr du client canonique, via le résolveur d’identité Core 4.5.4.
- Les contrôles restent stricts : campagne publiée, statut actif, Dialer activé, numéro Twilio présent et identité cliente reliée de façon sûre.
- Les nouveaux appels sortants lancés depuis le Hub Client sont attribués à la fiche canonique portée par la session lorsque la campagne conserve encore un ancien propriétaire technique.

## 1.4.0 — 2026-08-18

- CallTracker AWM 1.4.0 devient la référence officielle du shell visuel AWM partagé. Son ancien en-tête spécifique est remplacé par le shell Core afin d’éviter les doublons tout en conservant toutes les routes et fonctions existantes.


## Sécurité 1.3.7 — 2026-08-17

- CallTracker AWM 1.3.7 utilise le coffre Core 4.4.0 pour protéger au repos les secrets Twilio et Google Ads sans modifier les routes historiques.
# Changelog — CallTracker AWM

## 1.3.6 — 2026-08-17
- Les routes REST historiques Twilio `/callink/v1/token`, `/voice`, `/incoming` et `/status` sont désormais enregistrées exclusivement par Core AWM 4.3.9.
- CallTracker conserve le traitement métier Twilio mais n’est plus propriétaire de la surface API publique.
- Les URL historiques restent strictement inchangées.


## 1.3.5 — 2026-08-17
- Les campagnes historiques mises à la corbeille ou supprimées définitivement sont maintenant inscrites dans une liste d’exclusion persistante (`callink_legacy_campaign_tombstones`).
- Les synchronisations/migrations depuis l’ancienne plateforme ignorent systématiquement ces campagnes et ne peuvent plus les republier ni les recréer automatiquement.
- Une campagne déjà présente dans la corbeille au moment d’une synchronisation est automatiquement protégée contre la résurrection.
- Une restauration WordPress explicite retire l’exclusion et autorise de nouveau la synchronisation de cette campagne.
- Les exclusions et restaurations sont consignées dans le journal de sécurité Core lorsqu’il est disponible.

## 1.3.4 — 2026-08-17
- Correctif global des associations historiques Clients ↔ Campagnes : les campagnes liées à une ancienne adresse du même client sont maintenant visibles dans la fiche CallTracker canonique lorsqu’une correspondance sûre peut être établie.
- Exemple couvert : une campagne liée à `info@domaine.tld` et une fiche WHMCS liée à `proprietaire@domaine.tld`, avec identité cohérente.
- Aucun rattachement n’est réécrit silencieusement; les consolidations permanentes restent soumises au rapprochement global contrôlé.


## 1.3.3 — 2026-08-17
- Rapprochement global de l’ensemble des anciennes fiches CallTracker vers les fiches WHMCS canoniques, avec fusion en lot limitée aux correspondances sûres et uniques.
- Les campagnes, appels et formulaires suivent la fiche canonique après rapprochement; les cas ambigus restent visibles pour validation manuelle.
- Correction du rendu réel des écrans WordPress de campagnes : retrait du logo historique dupliqué et conservation d’un seul en-tête CallTracker en haut.
- Harmonisation complète du listing et de l’éditeur Campagnes en clair/sombre, incluant champs, metaboxes, publication, tableaux et actions.
- Compatibilité des associations clients historiques : les campagnes liées par ID WHMCS ou courriel sûr apparaissent dans la fiche CRM/WHMCS canonique.
- Agrégation des compteurs de campagnes, appels et formulaires sur les références sûres du même client.

## 1.3.2 — 2026-08-17
- Amélioration du parcours Campagnes : visualisation consolidée des appels et formulaires par campagne.
- Campagnes associées visibles depuis la fiche client avec compteurs et accès direct à l’activité.
- Harmonisation visuelle de l’administration Campagnes et en-tête CallTracker avec le thème AWM.


## 1.3.1 — 2026-08-17

- Activation ou désactivation d’un client pour CallTracker sans modifier son statut WHMCS/CRM.
- Les clients CallTracker actifs sont les seuls proposés lors de la création d’une campagne avec achat Twilio.
- Rattachement direct d’une campagne existante non assignée depuis l’écran Clients.
- Préselection du client lors de l’ouverture de « Nouvelle campagne ».
- Refus serveur d’un achat ou d’un jeton Dialer client lorsque CallTracker est désactivé pour ce client.
- Compatibilité préservée pour les clients ayant déjà des campagnes historiques.


## 1.3.0 — 2026-08-17

- Ajout d’un accès Clients directement dans CallTracker AWM.
- Recherche des clients par nom, entreprise, courriel, téléphone, campagne ou numéro Twilio.
- Filtres Actifs, Inactifs et Tous disponibles depuis CallTracker; les clients inactifs restent masqués par défaut.
- La référence WHMCS demeure la source du statut actif, avec respect des exceptions manuelles et de la fiche interne Alliance Web Marketing.
- Réutilisation de la route historique `callink-clients` et des métadonnées existantes, sans nouvelle table ni duplication de clients.

# Historique — CallTracker AWM

## 1.2.0 — 2026-08-17

- Contrat de permissions Core AWM 1.0 appliqué aux campagnes, numéros, historique et CPL.
- Niveaux distincts pour consultation, opérations quotidiennes, approbation et réglages.
- Signatures Twilio refusées consignées dans le journal central avec limitation anti-bruit.
- Diagnostic Core des webhooks Twilio et du Dialer.
- Activation arrêtée proprement avec Core antérieur à 4.3.0, sans modification des campagnes ni de l’historique.

## 1.1.2 — 2026-08-15

- Libération explicite d’un numéro Twilio sans recopie manuelle.
- Comparaison serveur du numéro enregistré avant l’appel irréversible à Twilio.