Contexte développement

# Contexte développement — Hub Client AWM 1.14.44


---

## CHANGELOG.md

# Hub Client AWM 1.14.44

Suite AWM 4.5.470 — Identité de l’en-tête client · 22 octobre 2026.

Hub Client 1.14.44 affiche le logo client seul dans le bloc de marque; à défaut, favicon et noms de compagnie/utilisateur; à défaut, logo AWM et ces noms. Les images défaillantes passent au repli suivant. Le rendu garde proportions, accessibilité et largeur mobile, sans changer les préférences d’apparence.

Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.470.md. Les vérifications locales du code et du navigateur ne constituent pas une installation WordPress ni une validation sur le site de production.

---

# Hub Client AWM 1.14.43

Suite AWM 4.5.469 — Aperçu avant enregistrement · 22 octobre 2026.

Deux démonstrations clair/sombre réagissent immédiatement aux choix du formulaire avec le CSS réel du portail : carte, H1/H2/H3, texte, boutons, champ, badge et indicateur. Neutral propose les détails de cinq rôles, les polices détectées ou en bibliothèque et les poids contrôlés 100..900; les recettes nommées restent complètes. Les modifications restent locales jusqu’à Enregistrer les deux profils; la bascule du haut conserve son comportement.

Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.469.md. Les essais utilisent le code PHP/CSS/JavaScript réel avec services WordPress substitués; ils ne valent pas installation ou validation sur le site de production.

---

## 1.14.42 — 2026-10-22

Suite AWM 4.5.468 — Bascule clair/sombre et profils distincts.

Le bouton ◐ connecté est de nouveau une vraie bascule : changement immédiat, enregistrement authentifié du mode seul, retour visible en cas d’erreur et formulaire de repli sans JavaScript. Apparence présente Paramètres clairs et Paramètres sombres, chacun avec les six axes du catalogue et cinq couleurs de surface. Les polices Neutral, leurs graisses et la couleur secondaire sont explicitement communes. Les éditions en cours restent intactes pendant une bascule.

Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.468.md. Aucune installation ni publication de cette version sur l’hébergement n’est présumée.

---

## 1.14.41 — 2026-10-22

Le formulaire existant propose Automatique · logo puis site, Toujours sombre et Toujours clair. Son aide explique la mémorisation du choix et sa priorité sur l’analyse automatique. Les contrôles de persistance utilisent le vrai formulaire, le handler du portail et le callback Core, avec transport et stockage de test. Le choix du portail reste indépendant du mode administratif.

## Validation et portée

Cette version fait partie de Suite AWM 4.5.466. Les preuves détaillées sont dans `PREUVES-VALIDATION-SUITE-AWM-4.5.466.json` et le rapport `VALIDATION-SUITE-AWM-4.5.466.md` de la Suite. Elles couvrent le rendu PHP et Chromium, les modes opposés, les bascules, les identités distinctes et la persistance du choix du portail. Les tests s’exécutent localement avec données et services WordPress substitués; ils ne constituent pas une installation sur le site de production.

Les préférences client ne sont pas modifiées par l’ouverture d’une carte ou d’une fiche administrative, ni par une bascule Core. Les anciennes notes ci-dessous restent historiques : pour cette livraison, les cartes et fiches administratives utilisent la variante Core, tandis que Hub Client conserve son choix indépendant.

---

## 1.14.40 — 2026-10-22 · Suite AWM 4.5.464

- Consomme les six axes résolus par Hub depuis les indices logo/site ou le choix manuel; le rapprochement du catalogue reste partagé, sans classificateur local.
- Consomme l’apparence client canonique `color_scheme` / `resolved_color_scheme` indépendamment de Core.
- Applique l’apparence automatique provenant du logo/site et conserve la priorité d’un choix manuel Clair/Sombre.
- Préserve la personnalisation du thème et le retour volontaire au profil automatique, avec le catalogue partagé existant.
- Charge le profil avant le head et réutilise la réponse, avec snapshot existant en repli; ni le système ni localStorage ne remplacent le mode canonique.
- Corrige la sérialisation des piles de polices dans un attribut style échappé une fois; conserve les variables CSS valides.
- Oriente le bouton de mode authentifié vers Apparence et sa sauvegarde via le POST/API existant; l’aperçu non authentifié reste temporaire.
- Supprime les valeurs fixes qui masquaient les tokens de densité du profil; Compact, Standard et Confortable pilotent les espacements, panneaux, champs et cellules.
- Actualise la documentation de cette livraison; aucune publication ou validation d’hébergement n’est présumée.


## 1.14.39 — 2026-10-21

- L écran Apparence consomme le catalogue Design Composer reçu de Core/Hub AWM au lieu de maintenir un catalogue figé.
- Le client voit la source de son thème recommandé et peut personnaliser famille, couleur, typographie, surface, mouvement et densité.
- Le bouton de réinitialisation devient `Revenir au thème automatique · logo -> site -> AWM`.
- Les tokens compilés par Core sont prioritaires pour géométrie, typographie, surfaces, mouvement et rythme du portail.
- Le même profil visuel est appliqué aux vues Accueil, CRM, Stats, LeadTracker/CallTracker, Soutien, Assistant et futurs services compatibles rendus dans le portail.
- `prefers-reduced-motion` reste prioritaire.

## 1.14.38 - Surface & Mouvement v2 du portail (2026-10-21)
- Étend le portail à 12 surfaces et 12 mouvements.
- Les surfaces Flat, Outline, Soft tint, Elevated, Floating, Inset, Layered, Glass, Frosted, Gradient et Glow ont des rendus réellement distincts en Light/Dark.
- Les mouvements disposent de durées, courbes et interactions propres; reduced-motion neutralise toujours les animations.
- Studio accepte les mêmes styles page-scoped.

## 1.14.37 - Application page-scoped du Design Composer Studio (2026-10-21)
- Accepte `design_profile` et `design_tokens` depuis Studio lors de la création de page.
- Applique accent, géométrie, typographie, surface, mouvement et densité au blueprint de la page sans charger le CSS admin Core.
- Ajoute stagger de section et CTA glow aux effets Studio, avec garde `prefers-reduced-motion`.
- Stocke les métadonnées de design utilisées par la page pour audit/reprise.
- Ne modifie pas automatiquement les Global Colors/Fonts ni le Site Kit Elementor existant.

## 1.14.36 - Design Composer v2 du portail (2026-10-21)
- Consomme les axes Typographie, Surface et Mouvement publiés par Hub/Core.
- Ajoute 5 personnalités typographiques, 5 styles de surface et 3 niveaux de mouvement.
- Neutral conserve les polices client détectées/manuelles; les autres familles utilisent des piles locales contrôlées.
- `prefers-reduced-motion` désactive les transitions même si le profil sélectionne Fluide.
- L écran Apparence expose les nouveaux axes avec Famille, Couleur et Densité.

## 1.14.35 - Design dynamique du portail (2026-10-21)
- Hub Client consomme famille visuelle, couleur et densite publiees par Hub/Core.
- Ajoute 10 familles compatibles : Square, Arctic, Graphite, Electric, Console, Rounded, Soft, Outline, Minimal, Glass.
- Light/Dark reste independant et les couleurs de texte des boutons sont ajustees selon le contraste.
- L ecran Apparence permet aussi de configurer famille, roue couleur et densite.

## 2026-10-20 - Hub Client AWM 1.14.34 - identite formulaire harmonisee pour Capturia
- Le miroir local chiffre utilise le meme contrat de nom humain que LeadTracker.
- Email, telephone et URL ne peuvent plus etre promus comme nom/prenom.
- Alias `Nom du lead`, `Nom du prospect`, `Nom du contact`, nom complet, prenom et nom de famille reconnus.
- Le fallback Capturia local historique recoit la meme normalisation pour eviter une divergence avec le moteur central.
- `central_owned=1` reste la regle normale : Hub Client ne cree pas un deuxieme contact Capturia.

## 2026-10-18 - Hub Client AWM 1.14.33 - mappings de campagne actifs auto-appliqués

- Hub Client ne dépend plus d’un clic administrateur pour appliquer les mappings d’une campagne active.
- Un worker local actualise les campagnes/mappings Alliance toutes les cinq minutes et remplace automatiquement les associations gérées par Alliance; une campagne mise en pause disparaît donc du routage géré lors de la prochaine synchronisation.
- Chaque vraie soumission Elementor, Gravity Forms, Contact Form 7 ou hook AWM force en plus une lecture fraîche de `forms/campaigns` avant de résoudre la route. Une campagne activée ou modifiée quelques secondes auparavant ne peut plus être masquée par le cache de cinq minutes.
- Les mappings explicites restent prioritaires et VMV-NAT conserve son fallback `capturia_auto_all_forms`.
- Aucune soumission historique n’est rejouée par ce worker; il ne fait que synchroniser la configuration de routage.

## 2026-10-18 - Hub Client AWM 1.14.32 - complément données du moteur Capturia central

- Quand LeadTracker indique `central_owned=1`, Hub Client ne crée plus de contact Capturia et ne retague pas Google.
- Si le mode confidentialité local est actif, LeadTracker retourne le contact Capturia exact et un reçu technique lié au `local_ref`; Hub Client ajoute uniquement les notes complètes depuis le miroir local chiffré.
- Le complément utilise les mêmes clés d'idempotence et la même preuve centrale; aucun doublon de contact n'est créé.
- Le chemin normal sans mode confidentialité est entièrement pris en charge par LeadTracker et Hub Client reste passif.

## 2026-10-16 - Hub Client 1.14.31 / Suite AWM 4.5.424 - Capturia immédiat sur le lead exact

- Corrige la file FIFO du chemin de capture : un nouveau formulaire ne peut plus être bloqué derrière d'anciens `pending/retry`. `process_queue('capture')` traite maintenant le `local_ref` exact qui vient d'entrer.
- Dès que LeadTracker retourne son `form_row_id`, Hub Client envoie immédiatement un reçu technique `En attente` sans PII. La ligne ne doit donc plus rester silencieusement `Sans preuve` pendant la préparation Capturia.
- Le flux normal est synchrone : formulaire réel → LeadTracker → Capturia contact → étiquette Google → toutes les notes/données → reçu `accepted`, dans la même requête.
- Les notes multiples ne sont plus espacées de 15 secondes en fonctionnement normal; tous les blocs sont envoyés immédiatement. Seuls HTTP 429, erreur réseau incertaine ou refus API arrêtent le flux et déclenchent la reprise sûre.
- Les clés d'idempotence restent inchangées et une réponse mutative incertaine n'est jamais rejouée aveuglément. Aucun historique n'est relancé automatiquement.

## 2026-10-16 - Hub Client 1.14.30 / Suite AWM 4.5.420 - Capturia déclenché par la réponse autoritaire du lead

- Corrige le défaut terrain persistant où un lead VMV-NAT entrait dans LeadTracker mais restait `Sans preuve` sans jamais atteindre la file Capturia.
- Le flux ne dépend plus d'une seconde lecture de `forms/campaigns` après la capture. LeadTracker retourne avec `forms/submit` une instruction PII-free pour la campagne exacte; Hub Client l'utilise immédiatement.
- Séquence normale : miroir local chiffré → `forms/submit` → instruction Capturia autoritaire → file idempotente locale → création contact → étiquette Google → données → reçu technique LeadTracker, dans le même traitement.
- Si la clé, les scopes, l'étiquette ou le Connector empêchent l'envoi, la ligne locale passe en reprise contrôlée et une preuve technique peut remonter; elle ne doit plus rester silencieusement `Sans preuve`.
- Le cron n'est qu'un secours. Aucun des historiques 563 n'est rejoué et une réponse réseau incertaine n'est jamais renvoyée aveuglément.

## 2026-10-16 - 1.14.29 / Suite AWM 4.5.419 - Capturia immédiat sans relecture de cache au verrou final

- Corrige le défaut terrain de 1.14.28 : `on_form_captured()` lisait bien VMV-NAT en mode frais, mais `enabled()` puis `process_queue()` pouvaient relire aussitôt le cache précédent et interrompre l'envoi.
- Le chemin de capture force désormais le contrat frais de bout en bout (`target(true)`, `enabled(true)`, `process_queue('capture')`) avant toute écriture Capturia.
- Tout nouveau formulaire VMV admissible est mis en file idempotente et traité immédiatement dans la même requête. Le cron reste uniquement une reprise contrôlée sur erreur/rate-limit.
- Les mappings explicites vers une autre campagne restent prioritaires; aucun historique n'est rejoué automatiquement et les réponses réseau incertaines restent non rejouées aveuglément.

## 2026-10-16 - 1.14.28 / Suite AWM 4.5.418 - Capturia immédiat sans cache périmé

- Force une lecture fraîche du contrat VMV-NAT/Capturia au moment de chaque capture afin qu'un cache de campagne antérieur à `capturia_auto_all_forms` ne puisse plus faire sauter silencieusement l'envoi.
- Garantit la création/présence de la file Capturia même si le miroir chiffré possède déjà la soumission; l'idempotence est conservée par `local_ref`.
- Après une capture admissible, la file est traitée immédiatement; les crons restent uniquement des reprises contrôlées.
- Aucun historique n'est rejoué automatiquement et une livraison incertaine n'est jamais relancée aveuglément.

## 2026-10-15 - 1.14.27 / Suite AWM 4.5.416 - Capturia immédiat à la soumission

- Tout nouveau formulaire VMV admissible est envoyé à Capturia immédiatement dans le même flux que sa capture locale; aucun délai normal de 36 h, 65 s ou cron n'est requis.
- La file locale reste la source idempotente et ne sert qu'à une reprise contrôlée si Capturia, la clé ou le réseau sont momentanément indisponibles.
- Une réponse réseau incertaine reste en état `uncertain` et n'est jamais rejouée aveuglément.
- L'association explicite à une autre campagne reste prioritaire; VMV-GADS, VMV-FADS, VMV-YT et les autres campagnes ne sont pas déplacées vers VMV-NAT.
- Aucun historique n'est relancé automatiquement. Le mécanisme de rattrapage 36 h des versions précédentes n'est plus exécuté par 1.14.27.

## 2026-10-15 - 1.14.26 / Suite AWM 4.5.415 - VMV-NAT Capturia automatique pour tous les formulaires

- Quand la destination Capturia est active sur VMV-NAT, tout formulaire capturé sur le WordPress principal de Vendre Maison Vite est automatiquement attribué à VMV-NAT et mis en file Capturia, sans exiger une sélection manuelle formulaire par formulaire.
- Une association explicite du formulaire à une autre campagne reste prioritaire : VMV-GADS, VMV-FADS, VMV-YT et toute autre campagne ne sont jamais déplacés silencieusement vers VMV-NAT.
- Elementor, Gravity Forms, Contact Form 7 et le hook générique Hub Client suivent le même contrat. Les moteurs futurs qui passent par le hook générique héritent automatiquement du routage.
- Le rattrapage récent 36 h est versionné à nouveau afin de mettre en file les captures VMV-NAT récentes sans livraison locale, sans rejouer les 563 historiques et sans dupliquer une ligne déjà livrée.
- Capturia reçoit toutes les données métier utiles du formulaire; la preuve renvoyée à Alliance reste strictement PII-free.

## 2026-10-15 - 1.14.25 / Suite AWM 4.5.413 - Capturia multi-formulaires et rattrapage recent cible

- Corrige le routeur Capturia VMV-NAT qui etait encore limite a `hub_client_elementor` dans 1.14.24. Les formulaires explicitement mappes Elementor, Gravity Forms et Contact Form 7 suivent maintenant le meme circuit Capturia.
- Chaque capture calcule un `submitted_at_utc` canonique. Gravity Forms `date_created` est interprete comme UTC; les autres sources historiques sont converties depuis le fuseau WordPress vers UTC.
- Le recu de preuve PII-free ajoute source, identifiant de formulaire, phase et curseur de notes afin que LeadTracker affiche les etapes de livraison.
- A la premiere synchronisation 1.14.25, un rattrapage borne aux 36 dernieres heures inspecte le miroir local chiffre, resoumet les formulaires au registre central avec leur identifiant stable, puis met en file Capturia uniquement les lignes qui n ont jamais eu de livraison locale.
- Ce rattrapage est idempotent, ne rejoue jamais le backfill historique des 563 lignes et ne cree pas une deuxieme ligne Capturia lorsqu une livraison locale existe deja.
- Aucun envoi fournisseur n est execute pendant l installation elle-meme; le worker reste asynchrone et respecte les pauses HTTP 429.

## 2026-10-15 - 1.14.24 / Suite AWM 4.5.410 - VMV-NAT : données CRM complètes et identité visible

- Capturia demeure le CRM du client Vendre Maison Vite : le contact reçoit le nom, le courriel et le téléphone structurés, puis **toutes les réponses utiles du formulaire Elementor** sont conservées dans une ou plusieurs notes Capturia.
- Les champs techniques sensibles (mot de passe, jeton, nonce, captcha, clé API, carte/CVV) sont volontairement exclus du transfert CRM.
- Si les réponses dépassent une note, Hub Client les découpe en notes idempotentes et reprend automatiquement après HTTP 429 sans perdre les parties déjà acceptées.
- Le transport `local_mirror_v1` transmet désormais à LeadTracker uniquement l identité opérationnelle minimale (nom, courriel, téléphone) afin que la liste affiche le vrai contact; le reste du formulaire demeure dans le miroir local chiffré et dans Capturia.
- La table de **preuve Capturia** reste strictement sans PII : identifiants techniques, statut, HTTP/request ID et horodatage seulement.
- Aucun envoi n est déclenché par l installation; le routage reste limité au site principal Vendre Maison Vite et à VMV-NAT.

## 2026-10-15 - 1.14.23 / Suite AWM 4.5.409 - Capturia : preuve de livraison des nouveaux formulaires

- Après l enregistrement central du formulaire, le Hub Client rattache l identifiant technique AWM à la file locale Capturia et renvoie à Alliance un reçu **sans PII** après chaque changement d état.
- Le reçu contient uniquement les identifiants techniques, l état, le code HTTP, l identifiant de requête et l horodatage; aucun nom, téléphone, courriel ni contenu de formulaire n est renvoyé pour cette preuve.
- Les nouveaux envois VMV-NAT respectent `Retry-After` / `RateLimit-Reset`, n utilisent plus une limite fixe de quatre essais sur HTTP 429 et ne traitent qu une ligne Capturia par passage afin de réduire les nouvelles limites API.
- Le prochain passage est replanifié automatiquement lorsqu une ligne reste à envoyer. Les clés d idempotence existantes sont conservées.
- AWM n appelle aucune fonction SMS/courriel Capturia. Les automatisations éventuellement configurées dans le compte Capturia restent hors du contrôle d AWM.
- Aucun formulaire n est envoyé à l installation; la route reste strictement limitée au site principal Vendre Maison Vite et à VMV-NAT.

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

Registre local CRM multicanal avec transactions, charges nominatives chiffrees par Core, index tenant-scopes, endpoints prives et vue du portail CRM.

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.

---

## 1.14.21 — VMV-NAT / Capturia Google avec la clé déjà enregistrée — 2026-10-12
- Site principal : réception des formulaires Elementor déjà appairés dans LeadTracker, conservation chiffrée locale et file anti-doublons.
- Lorsque l'opérateur coche Capturia Google dans LeadTracker, le site vérifie automatiquement (cron + reprise de formulaire) la clé existante reçue via Connector authentifié, les scopes contacts:write/tags:read et l'étiquette existante Google, sans nouveau champ API.
- Envoi sécurisé POST /contacts, puis ajout du tag Google, puis note de provenance VMV-NAT (SEO) ; aucun SMS ; réponses réseau incertaines stoppées pour vérification, sans double envoi aveugle.
- La route est coupée si l'intention centrale est désactivée, la campagne est en pause ou la source SEO / formulaire n'est plus conforme ; ne touche pas aux imports Google Ads.

# 1.14.20 — 2026-10-12 — Urgent: exactitude UTF-8 Elementor / snapshots
- Corrige la lecture du JSON `_elementor_data` : aucune application de `wp_unslash()` aux valeurs déjà reçues de `get_post_meta`; préserve `\u00e9`, `\u2019`, `\n` ainsi que les valeurs HTML et les données des autres widgets.
- Les snapshots préalables conservent maintenant les octets exacts du document; la restauration utilise la valeur originale correctement protégée par `wp_slash()` à la sauvegarde.
- Vérifie avant toute écriture que seuls les widgets explicitement demandés ont changé; compare le document réellement relu après écriture et annule la transaction en cas d'écart.
- Détecte une page déjà abîmée par l'ancien moteur et refuse toute nouvelle écriture jusqu'à restauration d'une révision saine; refus d'un ancien snapshot corrompu connu.
- Le scan/score SEO local lit aussi le JSON Unicode sans décapage des échappements.
- Les anciennes pages endommagées ne peuvent PAS être restaurées automatiquement par cette mise à jour : utiliser une révision Elementor/WordPress antérieure ou un backup vérifié.

# 1.14.19 — 2026-10-11 — Form Guard Elementor, arrêt avant email client
- Ajoute le garde de validation Elementor Pro à priorité 1, avant actions Email / Email2 / webhooks / CRM / LeadTracker.
- Réponse AJAX de validation en erreur lorsqu'un spam est rejeté; aucune suppression d'email **après** envoi.
- Défense en profondeur dans `capture_elementor` contre une capture forcée après refus.
- Règles locales graduelles : preuve JavaScript HMAC courte durée, champ piège, liens de masse, injection HTML, email incohérent, rafales IP/agent et doublons hachés.
- Aucun secret ni contenu de formulaire envoyé à Alliance pendant la décision anti-spam; journal limité à 150 événements sans coordonnées personnelles.
- Nouvelles routes REST protégées par le secret de scan existant : `tech/form-guard/policy` et `tech/form-guard/status`.
- Dépendance Elementor Pro uniquement si présent; aucune modification des actions Gravity Forms et Contact Form 7.
- Tests unitaires avec doubles WordPress validés; **test réel Elementor Pro / email client à faire** avant déploiement massif.

# 1.14.18 — CRM Client AWM local, chiffrement et LeadTracker — 2026-10-07
- Ajoute la table locale `awm_client_data_mirror`; le payload complet est conservé uniquement sous forme chiffrée authentifiée.
- Ajoute le module **CRM Client AWM** dans le Hub client avec résumé et boîte de réception des leads locaux.
- Les formulaires restent enregistrés localement même si l envoi vers Alliance échoue.
- Lorsque CRM Client AWM est activé, le transport central passe en `local_mirror_v1` et ne transmet pas les valeurs nominatives brutes.
- L état des modules est relu par canal Connector authentifié et dispose des mêmes replis de transport que Tech/Stats.
- Le produit visible CallTracker devient **LeadTracker AWM** dans Hub Client, sans changer les routes techniques historiques.

# 1.14.17 — détection Elementor exhaustive et diagnostic de scan — 2026-10-02
- Corrige le scan Elementor qui ne regardait que les 180 documents les plus récents.
- Cherche d'abord les documents `_elementor_data` contenant un widget `form`, jusqu'à 1500 candidats, avec repli borné jusqu'à 2000 documents.
- Utilise l'API Documents Elementor quand elle est disponible, puis `_elementor_data` comme repli.
- Analyse aussi les structures `children` en plus de `elements` pour les containers imbriqués/addons compatibles.
- Remonte un diagnostic `elementor_scan` (candidats, documents analysés, formulaires trouvés, état Elementor Pro) à CallTracker.
- Étend les identifiants runtime Elementor (`form_id`, `widget_id`, `form_widget_id`) pour améliorer l'appariement à la soumission.

# 1.14.16 — scan formulaire étendu + Contact Form 7 — 2026-10-01
- Corrige la détection Elementor lorsque `form_id` existe mais est vide : repli sur `form_name`, puis l’ID du widget.
- Ajoute l’inventaire automatique Contact Form 7 et son indicateur d’activation.
- Ajoute la capture native `wpcf7_mail_sent` vers CallTracker avec ID numérique stable du formulaire.
- Accepte les mappings Alliance `contactform7` et conserve le cloisonnement exact par WordPress.

## 1.14.15 — inventaire formulaires disponible au status — 2026-10-01
- La réponse privée `update/status` inclut maintenant l inventaire Gravity Forms/Elementor du WordPress courant.
- Core peut donc actualiser la détection à la demande depuis CallTracker sans attendre la synchronisation horaire du site.
- La synchronisation horaire existante reste inchangée et continue d envoyer le même inventaire sans requête supplémentaire.

## 1.14.14 - inventaire formulaires pour CallTracker - 2026-10-01
- Détecte les Gravity Forms actifs et les widgets Elementor Pro Form sur le WordPress courant.
- Joint cet inventaire à la synchronisation de modules déjà existante, sans créer de rafale HTTP supplémentaire.
- Conserve le site exact (home_url, chemin inclus) afin de distinguer un WordPress racine d un WordPress /region.

# 1.14.13 — 2026-10-01

- Les mappings CallTracker peuvent cibler un site WordPress exact, chemin inclus.
- Un Hub Client ne synchronise que les formulaires qui ciblent son `home_url()`; un mapping historique sans site explicite reste accepté pour compatibilité.
- Permet à une même campagne de couvrir plusieurs WordPress distincts, par exemple `plomberiesoltech.com` et `plomberiesoltech.com/region`.

# 1.14.12 — 2026-10-01

- Hub Client accepte maintenant plusieurs mappings de formulaires publiés par une même campagne CallTracker.
- Synchronisation rétrocompatible : `form_mappings` est prioritaire et l ancien `form_mapping` unique reste accepté.
- Chaque mapping central reçoit une identité stable indépendante afin de pouvoir mélanger Gravity Forms et Elementor sans écraser les autres attributions.

## 1.14.11 — 2026-10-01
- Si un téléchargement HTTP 2xx en mode stream produit un fichier de 0 octet, Hub Client refait une seule requête non streamée puis écrit le corps reçu dans le fichier temporaire.
- L’erreur `awm_update_download_empty` n’est renvoyée qu’après échec des deux méthodes.

## 1.14.10 — 2026-10-01
- La garde Recovery est temporairement différée pour les mises à jour automatiques de flotte.
- Les modules AWM passent par le chemin local avec SHA-256, sauvegarde et rollback.
- Les extensions WordPress tierces automatiques utilisent le chemin protégé local avec backup, version exacte et sonde HTTP.
- Recovery reste installé et pourra être réactivé ultérieurement via `AWM_RECOVERY_ENFORCEMENT_ENABLED`.

## 1.14.9 — 2026-10-01
- Certification Recovery asynchrone persistante : le test complet fichiers + SQL s execute en arriere-plan sur le site sans bloquer le worker central.
- Nouvelle file locale Recovery avec etats queued/running/complete/failed et reprise idempotente.
- La route privee `tech/recovery/prepare` expose `async_mode=start|status`; le chemin synchrone reste disponible pour diagnostic manuel.

## 1.14.8 — 2026-10-01
- Recovery accepte les bases MySQL partagees lorsque les tables de ce WordPress sont isolables par son prefixe SQL.
- La certification automatique ne demande plus une base dediee : seules les tables du prefixe du site sont capturees, testees et restaurees.
- Les tables appartenant aux autres WordPress de la meme base ne sont jamais touchees.

## 1.14.8 — 2026-10-01
- Ajoute le mode de preparation Recovery `automatic_scope` utilise par Core 4.5.257 pour le parcours zero-clic.
- Le scope n est accepte automatiquement que si les controles existants confirment une base dediee a ce WordPress et une implantation/Vault conforme; aucune preuve Recovery n est simulee.
- Le vrai checkpoint et le test fichiers + SQL restent obligatoires avant `recovery_ready_for_auto=1`.

# Changelog Hub Client AWM

## 1.14.6 — 2026-10-01
- Recovery automatique : si CREATE DATABASE est refuse, bascule vers le sandbox SQL par tables isolees du runtime Recovery 1.2.4.
- Le test SQL reste reel : import du dump, verification des comptes de lignes et nettoyage obligatoire avant `recovery_ready_for_auto`.
- La base temporaire distincte reste le premier choix lorsqu elle est autorisee.

# 1.14.5 — 2026-10-01

- Mapping formulaires piloté par campagne.
- Synchronise automatiquement les mappings Elementor/Gravity Forms définis dans CallTracker tout en conservant les mappings locaux manuels comme secours.

## 1.14.4 - Gravity Forms natif - 2026-09-30
- Ajoute le hook natif `gform_after_submission` sans dépendance dure lorsque Gravity Forms est absent.
- Détecte automatiquement les formulaires Gravity Forms actifs et permet leur attribution à une campagne CallTracker depuis Hub Client.
- Utilise l ID numérique du formulaire comme identifiant stable et l ID d entrée comme clé anti-doublon.
- Normalise et filtre les champs avant transport serveur-à-serveur; les champs sensibles connus restent exclus.
- Conserve intégralement le bridge Elementor existant.

## 1.14.3 - Installateur WordPress compatible - 2026-09-29
- Corrige la protection `upgrader_pre_install` qui bloquait par erreur l installation de toute nouvelle extension sur un site AWM appaire.
- L action WordPress `install` reste maintenant autorisee; les mises a jour/remplacements d extensions deja installees restent proteges par Tech/Recovery.
- Permet d installer le reparateur local AWM sans desactiver Hub Client lorsque le site est deja en 1.14.3+.
- Architecture Hub Client classique conservee; aucun MU permanent requis.

## 1.14.2 - Runtime classique unique - 2026-09-29
- Hub Client reste exclusivement dans `wp-content/plugins/hub-client-awm` comme architecture normale.
- Suppression de l auto-installation de AWM System Agent dans `mu-plugins`.
- Nouvelle preuve `classic_mode + boot_ok`; aucun System Agent n est requis pour confirmer la mise a jour.
- Le commit Deploy Engine v3 accepte officiellement le runtime classique 1.14.2+.
- Ajoute la route authentifiee `maintenance/classic-cleanup` pour retirer uniquement les anciens artefacts AWM MU apres un boot classique confirme.
- `safe_legacy` ne bloque plus l Autopilote; Recovery reste la porte obligatoire des mises a jour automatiques.

## 1.14.1 - Harmonisation flotte + auto-seed System Agent - 2026-09-29
- Hub Client reste en `safe_legacy`; aucune migration MU du runtime applicatif.
- Installe/met a niveau atomiquement AWM System Agent MU 2.0.1 dans `mu-plugins` lors d un boot sain.
- Un site ancien mis a niveau vers 1.14.1 devient donc reparable par le canal systeme a la requete suivante.
- N ecrase jamais un System Agent de version egale ou superieure.

## 1.14.0 - Safe Legacy + AWM System Agent - 2026-09-28
- Retire le cutover MU automatique du bootstrap Hub Client.
- Hub Client reste volontairement en plugin legacy pendant la stabilisation de flotte.
- Ajoute une preuve explicite `safe_legacy` + `boot_ok` dans l inventaire et update/status.
- Le futur plan de contrôle est confié à AWM System Agent MU 2.0.0, indépendant du runtime Hub Client.
- L Autopilote reste fail-closed: `recovery_ready_for_auto=0` en mode safe legacy.
- Aucun ancien runtime MU ni aucune sauvegarde n est supprimé.

## 1.13.9 - Stabilité flotte / cutover MU explicite seulement - 2026-09-28
- Une copie Hub Client chargée comme plugin legacy ne relance plus automatiquement `prepare()` ou le cutover MU.
- Sans autorisation temporaire explicite, l état devient `rescue_legacy`, la configuration MU est désactivée et le canal de mise à jour reste vivant.
- Les runtimes MU déjà complets restent inchangés et continuent de fonctionner.
- Aucun bypass Recovery; `recovery_ready_for_auto` reste faux en mode legacy de secours.

## 1.13.8 - Mode legacy de secours / reprise flotte - 2026-09-28
- Reconnaît l état MU `rescue_legacy` installé par AWM Hub MU Rescue 1.1.3 et suspend toute nouvelle tentative automatique de cutover MU.
- `update/status` expose `emergency_legacy_mode=1` lorsque le site est volontairement maintenu en runtime legacy sûr.
- `fleet_state` force `recovery_ready_for_auto=0` pendant le mode de secours; aucun Autopilote ne peut écrire dans cet état.
- `update/commit` accepte un commit `legacy_rescue` uniquement en mode administrateur manuel, avec version cible réellement chargée et état MU strictement `rescue_legacy`.
- Le commit conserve davantage de slots de transaction et marque `mu_deferred=1` au lieu de prétendre que la migration MU est complète.

## 1.13.7 - Inventaire et update/status anti-fatal - 2026-09-28
- Encadre l inventaire complet dans un filet `Throwable` et renvoie un inventaire minimal dégradé si une API/plugin ancien déclenche une exception.
- `update/status` ne doit plus transformer une erreur d inventaire locale en page WordPress « erreur critique »; il renvoie un diagnostic authentifié avec `degraded=1`.
- Le diagnostic conserve la version Hub/Tech détectable, l état minimal Recovery fail-closed et la dernière erreur utile sans exposer de secret.
- Ce mode dégradé sert uniquement à restaurer l observabilité et la reprise; il ne rend jamais `recovery_ready_for_auto` vrai.

# 1.13.6 — reprise automatique des bascules MU stagnantes — 2026-09-28
- Conserve intégralement le bootstrap fail-safe introduit en 1.13.5.
- Détecte `waiting_loader`, `cutover_pending` ou `waiting_runtime` restés plus de deux minutes sans preuve cohérente alors que la copie legacy est active.
- Supprime la preuve obsolète et reconstruit un runtime MU versionné depuis la copie Hub Client actuellement active.
- Évite qu une réactivation réussie laisse ensuite la migration MU figée sur la même version.
- Aucun bypass Recovery et aucune suppression de la copie legacy de secours.

# 1.13.5 — bootstrap MU fail-safe — 2026-09-28
- Corrige le fatal `Class "AWM_Client_Hub_MU" not found` observé pendant le chargement du plugin legacy.
- Le chargement de `class-awm-client-hub-mu.php` est désormais protégé et vérifie explicitement la présence réelle de la classe avant tout appel statique.
- En cas d opcode/require_once incohérent, Hub Client invalide OPcache pour ce fichier puis tente un unique rechargement contrôlé.
- Si la classe MU reste indisponible, le runtime legacy continue de charger au lieu de mettre WordPress hors ligne; le défaut est écrit dans le journal PHP.
- La migration MU, les preuves de nouvelle requête et `recovery_ready_for_auto` restent inchangées et fail-closed.

# 1.13.4 — préparation Recovery distante contrôlée — 2026-09-25
- Nouvelle route privée `tech/recovery/prepare`, authentifiée par le secret Connector.
- Répare/revalide l installation et la route Recovery avant toute autre étape.
- L analyse de périmètre confirme automatiquement uniquement les preuves déterministes (base dédiée au préfixe WordPress, implantation/Vault privés).
- La coordination des writers externes exige une confirmation administrateur explicite.
- Le test complet crée un checkpoint puis restaure fichiers + SQL dans une base temporaire distincte; cette base est supprimée ensuite.
- Aucun secret Recovery n est renvoyé à Core et `recovery_ready_for_auto` reste la seule preuve autorisant l automatique.

# 1.13.3 — état Recovery exploitable et transactions pré-promotion nettoyables — 2026-09-25
- `update/status` retourne maintenant le `fleet_state` complet utile à Core, dont `recovery_ready_for_auto`, sans secret.
- `tech/inventory` injecte le même `fleet_state` dans le profil Tech afin que l automatisation centrale connaisse réellement l état Recovery du site.
- Une transaction atomic_v3 restée en `verified` ou `staged` peut être abandonnée sans rollback : ces états précèdent le remplacement du dossier actif.
- Une nouvelle transaction nettoie automatiquement une préparation pré-promotion vieille de plus de 5 minutes avant de repartir avec un nouvel identifiant.
- L autopilote local aligne désormais son ordre sur Core : `Hub Client -> Tech AWM`.
- Les étapes après promotion (`awaiting_activation`, `awaiting_commit`, `committed`) conservent le rollback transactionnel strict existant.

# 1.13.2 — mises à jour tierces protégées utilisables — 2026-09-23
- Les mises à jour manuelles lancées depuis Tech privilégient Recovery complet; si ses preuves ne sont pas toutes prêtes, Hub Client utilise un secours local borné avec sauvegarde fichiers, paquet exact du fournisseur du site, vérification de version et sonde HTTP.
- Elementor Pro et les autres extensions premium utilisent exclusivement le paquet fourni par la licence du site; aucun paquet d un autre client n est réutilisé.
- Recovery embarqué reste byte-for-byte inchangé. Une intervention manuelle Tech privilégie Recovery complet; si ses preuves/politiques ne sont pas prêtes, le secours local borné de Hub Client prend le relais sans modifier le runtime Recovery du site. L automatique reste strictement soumis aux gardes Recovery existantes.
- Le blocage natif WordPress indique maintenant clairement de passer par Tech AWM pour une mise à jour protégée.

## 1.13.1 - writer Elementor securise etendu - 2026-09-23
- Étend le writer interne aux réglages canoniques Tech 1.9.0 pour widgets, containers, sections et colonnes.
- Ajoute flex/layout, bordures, responsive, images de fond et widgets natifs simples avec validation stricte.
- Conserve document_hash, snapshot avant écriture, validation de rendu et rollback existants.

## 1.13.0 - Deploy Engine v3, runtime MU immuable et rollback pre-plugins - 2026-09-22
- Le shutdown fatal est arme des le chargement MU, avant `plugins_loaded`, afin qu un fatal d une extension nouvellement promue puisse etre journalise puis rollbacke avant son prochain chargement.
- Les installations de nouveaux modules utilisent une phase `awaiting_activation`: activation WordPress dans une requete fraiche, puis `awaiting_commit`; aucune activation fictive par simple ecriture d option.
- Le preflight archive refuse ZIP bombs, chemins relatifs dangereux, liens symboliques, archive excessive et espace disque insuffisant avant toute promotion.
- La preuve Hub MU 1.13.0 exige desormais loader, fichier principal ET hash d arbre complet du runtime versionne.
- Le rollback v3 est idempotent et refuse un `deployment_id` qui ne correspond plus a la transaction courante.
- Les runtimes Hub Client MU sont desormais installes dans un chemin versionne unique; une mise a jour ne remplace plus le fichier PHP actuellement execute.
- Le loader MU 1.1.0 bascule uniquement le pointeur de configuration atomique vers le nouveau runtime; OPcache/LSAPI ne peut donc plus confondre deux versions sous le meme chemin.
- Introduit `atomic_v3` pour les modules AWM : verrou par module, `deployment_id`, journal persistant, preflight espace disque, staging, SHA-256, preuve d arbre, slot precedent, promotion, requete fraiche et commit.
- Une transaction deja promue est reprise sans deuxieme ecriture disque; un retry de Core reprend le `deployment_id` en attente de commit.
- Le slot precedent reste disponible tant que la nouvelle version n a pas passe sa preuve runtime.
- Le shutdown Hub Client enregistre les fatals sur une transaction non commitee; a la requete suivante Hub Client peut restaurer le slot precedent **avant le chargement des plugins normaux**.
- `update/status` expose les transactions v3 sans secret et `update/commit` finalise uniquement apres preuve locale de version/activation/runtime.
- HMAC, SHA-256, origine Alliance, `site_id`, permissions et garde Recovery restent inchanges.

# Hub Client AWM 1.12.2 - reprise automatique des migrations MU 1.12.0 bloquees

- Ajoute `activation_rescue()` : la reactivation manuelle du plugin Hub Client transforme un ancien etat MU incomplet en `rescue_requested`.
- Une requete normale suivante reconstruit le runtime MU depuis la version Hub Client active, ecrit un loader neuf et redemarre le parcours `waiting_loader -> cutover_pending -> waiting_runtime -> complete`.
- Si une mise a jour distante remplace directement une copie legacy active par une version plus recente, `tick()` detecte aussi la version superieure a la tentative precedente et relance `prepare()` sans intervention supplementaire.
- Le loader passe en 1.0.2; la bascule protegee introduite en 1.12.1 reste inchangee.
- La copie legacy reste le filet de secours et n est jamais supprimee automatiquement.

# Hub Client AWM 1.12.1 - bascule MU sans coupure du canal prive

- Remplace la desactivation persistante precoce du plugin legacy par une phase `cutover_pending`.
- Lors de la requete de bascule, le loader MU masque temporairement la copie legacy uniquement pour cette requete, charge le runtime MU, puis desactive la copie legacy de facon persistante seulement apres chargement reussi.
- Si le runtime MU echoue, les filtres temporaires sont retires et l activation legacy reste intacte; la requete suivante retrouve donc le canal REST normal.
- Une migration `failed` issue de 1.12.0 peut etre retentee automatiquement une seule fois lorsqu une version Hub Client plus recente est installee.
- Le loader passe en 1.0.1 et conserve le fallback hash/runtime, le scope multisite et la copie legacy de secours.

# Hub Client AWM 1.12.0 — agent MU permanent et registre de modules signé
- Migration automatique non destructive vers `wp-content/mu-plugins/awm-hub-client` avec petit loader stable `000-awm-hub-client-loader.php`.
- Migration en requêtes séparées : copie + loader en mode ombre, preuve `loader_alive`, désactivation de l ancienne activation WordPress, puis preuve `runtime_loaded` depuis une nouvelle requête.
- L ancienne copie sous `wp-content/plugins/hub-client-awm` reste sur disque comme filet de secours; elle n est jamais supprimée automatiquement.
- Une fois la migration `complete`, le loader MU retire immédiatement toute réactivation manuelle de la copie legacy avant le chargement des plugins; la copie legacy est aussi masquée de la liste Extensions normale tant que le runtime MU est sain.
- Si le runtime MU manque, ne correspond plus à son SHA-256 ou déclenche un `Throwable`, le loader désactive le runtime MU et restaure l activation legacy selon son périmètre site/réseau.
- Prise en charge multisite : conservation de la portée d activation avant migration et restauration au même niveau.
- `atomic_v2_mu` met à jour le runtime MU avec staging, backup, échange atomique, validation de version/hash et rollback local.
- `update/status` et `fleet_state` exposent l état MU sans divulguer de chemin serveur sensible.
- Registre dynamique de modules clients : un module inconnu n est accepté qu avec `module_spec` et `signature_v2` valides provenant de Core; dossier/fichier principal et droits distants sont liés par la signature.
- Autopilote Recovery reste fail-closed.

# Hub Client AWM 1.11.52 — moteur atomique hors Plugin_Upgrader
- Nouveau moteur `atomic_v2` pour les déploiements manuels Hub Client et Tech : téléchargement signé, SHA-256, sauvegarde locale, extraction en staging, validation de version puis échange atomique de dossier.
- `Plugin_Upgrader`, `activate_plugin()` et leurs hooks tiers ne sont plus utilisés dans le chemin manuel AWM.
- Tech nouveau est marqué actif dans l option WordPress sans exécuter de hook d activation dans la requête de remplacement; son vrai runtime ne charge qu à la requête suivante.
- Diagnostic persistant par étapes (`start`, `downloading`, `hash`, `backup`, `staging`, `swap`, `complete`, `fatal`) et capture du dernier fatal PHP nettoyé.
- `update/status` expose `deployment_engine`, `deployment_diagnostic` et `last_fatal`.
- Recovery automatique reste fail-closed.

# Hub Client AWM 1.11.51 — activation Tech en deux requêtes
- `update/apply` installe Tech sur disque mais ne l active plus dans la même requête PHP lorsque le déploiement est manuel.
- Nouvelle route privée `update/activate`, protégée par le même secret de site, qui active Tech dans une requête fraîche puis confirme version et état actif.
- `update/status` distingue maintenant version disque, plugin actif, runtime chargé et diagnostic d activation.
- En cas d interruption fatale pendant l activation, le paquet installé reste disponible et le diagnostic persistant indique la dernière étape au lieu de supprimer silencieusement Tech.
- Recovery automatique reste fail-closed; aucun assouplissement HMAC/SHA-256/permissions.

# Hub Client AWM 1.11.50 — déploiement manuel sans blocage Recovery

- Le canal manuel signé venant de Core peut installer Hub Client/Tech avec sauvegarde fichiers locale et rollback même lorsque Recovery complet n'est pas encore validé sur le site.
- Les mises à jour automatiques restent bloquées tant que `recovery_ready_for_auto` n'est pas confirmé.
- Le mode manuel n'affaiblit pas l'appairage, l'authentification du canal, la signature HMAC, le SHA-256, le contrôle du domaine Alliance ni la validation de version.
- Le hook Recovery de l'upgrader n'est pas relancé dans ce mode manuel afin d'éviter le même blocage; la sauvegarde locale de module reste obligatoire avant remplacement.

# Hub Client AWM 1.11.49 - Suite 4.5.235

- L'autopilote Hub Client/Tech est désormais bloqué tant que Recovery n'a pas `recovery_ready_for_auto`; chaque mise à jour AWM admise crée un point complet fichiers + BD via `admit-deploy` et exige un redémarrage frais via `finish-deploy`.
## 1.11.49 — Recovery auto-amorcé et télémétrie de sécurité — 2026-09-15
- Installe et raccorde automatiquement Recovery avec repli exact avant WordPress lorsque le serveur ignore la règle `.htaccess`, sans créer de dossier `/hub`.
- Adopte le raccord Bootstrap 1.1.3 déjà présent et conserve la sauvegarde privée du `index.php` original.
- Remonte à Tech uniquement des booléens de sécurité : intégrité route, périmètre backup confirmé, test de restauration et prêt pour automatisation; aucun secret.
- Les mises à jour automatiques restent bloquées jusqu'à validation réelle du périmètre et du test fichiers + SQL.

Date : 2026-09-15

Recovery 1.2.0 embarque, copie independante et installation automatique. Route /hub/recovery sans chargement WordPress. Archivage local avant transfert a Alliance; meme contenu sur plusieurs clients: pas de nouvel upload ZIP. Mise a jour tierce uniquement par le chemin protege, avec verifications fraiches.

Retention: version courante + cinq precedentes; sauvegardes completes: cinq. Pas de comptes generiques Tech 1/Responsable. Aucune migration destructive de donnees metier.

Candidate de stabilisation. Aucun deploiement effectue. Recette reelle WordPress + MySQL/MariaDB + PHP-FPM/OPcache + HTTPS et watchdog systeme obligatoire avant activation. Autopilote Suite AWM toujours suspendu. Les paquets des nouvelles mises a jour tierces proviennent encore du fournisseur WordPress de chaque site; leur telechargement unique depuis Alliance reste au roadmap.

## Historique

## 1.11.47 — Recovery externe et retention cinq versions — 2026-09-14

- Ajoute `recovery_available`, `recovery_url` et `recovery_cli_ready` au `fleet_state` compact.
- Intercepte `upgrader_pre_install` pour archiver l extension dans Recovery avant remplacement lorsque Recovery est configure.
- Une erreur de sauvegarde Recovery bloque la mise a jour; l absence de configuration Recovery conserve le comportement historique.
- Passe la retention locale de rollback de trois a cinq copies pour les modules AWM et extensions WordPress tierces.
- Aucun secret Recovery, mot de passe DB ou chemin serveur n est transmis a Alliance.

## 1.11.46 — Fraîcheur de flotte dans fleet_state — 2026-09-12

- fleet_state transmet maintenant l âge et la fraîcheur de l inventaire en plus des versions/autopilote/canal.
- Aucun secret Connector, chemin serveur ou clé API n est ajouté au payload.

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

- Envoie un `fleet_state` compact avec inventaire : versions runtime, autopilote, canal, dernier inventaire et dernier statut de mise à jour.
- Aucun secret Connector, chemin serveur ou clé API n est inclus dans cet état de flotte.

## Hub Client AWM 1.11.44 — bibliothèque WordPress

- Nouvelle route sécurisée `tech/plugin/install` pour installer, vérifier et activer une extension officielle WordPress.org demandée par Tech AWM.
- Les slugs AWM restent explicitement interdits sur cette route et continuent d utiliser le canal signé Core.
- La route réutilise l authentification Connector existante et vérifie la présence/version du plugin après installation.

# Hub Client AWM 1.11.43 — contrôles WordPress frais à la demande

- La route privée `tech/inventory` accepte `force_checks=1`.
- Une demande forcée relance `wp_update_plugins()`, `wp_update_themes()` et la vérification du Core WordPress avant de retourner l inventaire.
- Le cache d indexabilité Tech est invalidé afin que le statut Index/No-index reflète le contrôle demandé.
- Le mécanisme existant de mise à jour plugin conserve sauvegarde, validation de version, réactivation et rollback.

# 1.11.42 — autopilote AWM Hub Client + Tech

- Étend l autopilote stable à Tech AWM en plus de Hub Client.
- Tech est traité avant Hub Client afin de conserver l agent courant intact jusqu à la fin du cycle.
- Les autres modules centraux AWM ne sont jamais installés automatiquement sur un site client.
- Chaque paquet continue d utiliser publication Core, signature, SHA-256, sauvegarde et rollback.
- L inventaire Hub Client relit la version réellement présente sur disque après une auto-mise à jour pour éviter un statut temporairement périmé.
- Le contrôle s exécute de façon répartie par WP-Cron (premier passage environ 5 à 35 minutes après activation, puis chaque heure).

## 1.11.41 — 2026-09-11

- Ajoute l autopilote Hub Client : après appairage, une tâche horaire vérifie uniquement le canal stable Core et applique une nouvelle version Hub Client sans approbation WordPress répétée.
- Réutilise le paquet signé Core, la vérification SHA-256, le canal authentifié du `site_id`, la sauvegarde locale et le rollback déjà utilisés par la maintenance distante AWM.
- Ajoute la route privée `tech/plugin/update` permettant à Tech de mettre à jour une extension WordPress tierce précise avec sauvegarde locale des fichiers et vérification de version.
- Les modules AWM sont refusés sur cette route générique et restent exclusivement gérés par le canal Suite signé.
- En cas d accès fichiers non direct (`filesystem_method != direct`), la mise à jour automatique est refusée proprement plutôt que de demander des identifiants FTP.
- Les sauvegardes de plugin conservent les trois dernières copies locales par extension; le rollback de fichiers tente aussi de rétablir l état actif précédent.

## 1.11.40 — 2026-09-10
- Ajoute un fallback GeoIP serveur gratuit via **FreeIPAPI** lorsque les en-têtes de l hébergeur ne fournissent pas une vraie localité exploitable.
- Résout automatiquement ville, région, code région, pays, code postal et latitude/longitude approximatives pour les nouveaux visiteurs.
- FreeIPAPI n est appelé que si ville + coordonnées manquent; les en-têtes Cloudflare/GeoIP locaux et le filtre MaxMind local restent prioritaires.
- Cache le résultat GeoIP 12 h via une clé HMAC irréversible et limite volontairement Hub Client à 45 appels/minute pour rester sous la limite gratuite du fournisseur.
- L adresse IP brute n est jamais enregistrée dans WordPress ni envoyée à Alliance; elle est utilisée uniquement côté site client pendant le lookup GeoIP externe.
- Ajoute `geo_source` et `geo_precision` au contrat d événement afin que Stats sache distinguer localité GeoIP, région/pays et simple repli de fuseau.
- Le repli fuseau navigateur reste disponible pour diagnostic, mais ne doit plus créer artificiellement un point de visite sur la carte.


## 1.11.39 — 2026-09-10
- Corrige la carte historique Stats vide : le fuseau IANA du navigateur est maintenant envoyé avec tous les événements Web, pas seulement avec le heartbeat `presence`.
- Le contexte GeoIP approximatif déjà disponible côté hébergeur/reverse proxy est attaché aux page views, formulaires, conversions et engagements avant passage dans la file Connector.
- Ajoute les en-têtes de localisation courants Cloudflare, Vercel, CloudFront et GeoIP serveur comme sources facultatives.
- Aucune adresse IP ni position GPS n est transmise à Alliance; latitude/longitude restent arrondies à deux décimales.
- Cette évolution permet à Stats AWM d afficher les nouveaux points sur Aujourd hui / 30 jours / 3 mois au lieu de limiter la géographie au mode temps réel.

## 1.11.38 — 2026-09-09
- Ajoute le fuseau IANA du navigateur aux heartbeats `presence` comme repli cartographique approximatif lorsque le GeoIP local est incomplet.
- Le fuseau n'est envoyé que pour la présence temps réel et reste lié au contrat `client_id + site_id + instance_uuid`.
- Aucun GPS ni adresse IP n'est ajouté au tracker; GeoIP local reste prioritaire.

## 1.11.37 — 2026-09-09
- Ajoute le heartbeat `presence` Stats toutes les 20 secondes lorsque la page est visible.
- Accélère la remontée du heartbeat via wp-cron non bloquant afin d'alimenter la vue Visiteurs en direct.
- Résout localement une localisation GeoIP approximative depuis les en-têtes de l'hébergeur/reverse proxy lorsqu'ils existent.
- N'envoie jamais l'adresse IP ni une position GPS à Alliance; latitude/longitude GeoIP sont arrondies à deux décimales.
- Le heartbeat conserve le contrat `client_id + site_id + instance_uuid` et respecte la file Connector existante.

## 1.11.36 — 2026-09-09

- Après un appairage `AWM-SITE-*` réussi, Hub Client synchronise immédiatement le répertoire WordPress puis l inventaire Hub/Tech vers Core.
- Évite le cas où un site secondaire reste `Hub à vérifier` / inventaire non synchronisé jusqu à une action manuelle supplémentaire.
- La liaison reste valide même si le premier inventaire échoue; Hub Client journalise uniquement le code d erreur local et relance automatiquement au prochain cycle.
- Conserve le contrat `client_id + site_id + instance_uuid` et le tracker Stats first-party existant.

# CHANGELOG — Hub Client AWM

## 1.11.35 — 2026-09-09
- Migration automatique depuis les anciens plugins « Alliance Web Marketing Hub Connector », « AWM Hub Connector » et « CallInk Client Connector » : les anciennes copies actives sont désactivées lors de l'activation du Hub Client canonique.
- Génère l'`instance_uuid` dès l'activation afin qu'une nouvelle clé `AWM-SITE-*` puisse être appairée immédiatement à un site secondaire.
- Redirige les anciennes pages de réglages Connector vers `Hub > État de la liaison` pour éviter qu'un administrateur continue à utiliser une interface obsolète.
- Conserve le contrat multi-sites `client_id + site_id + instance_uuid`; aucun secret ou code de liaison n'est exposé dans l'interface ou les logs.
- La preuve runtime continue d'indiquer les anciennes copies désactivées automatiquement.

## 1.11.34 — 2026-09-08

- Ajoute le tracker Stats AWM automatique sur les pages publiques des sites jumelés.
- Les événements sont assainis localement puis envoyés en lot par le Connector; le secret Alliance n'est jamais exposé au navigateur.
- Chaque lot conserve le `client_id`, le `site_id` et l'`instance_uuid` du site connecté afin de distinguer site principal et sites secondaires.
- Suit pages vues, sessions/visiteurs pseudonymes, engagement, formulaires, conversions explicites, clics téléphone/courriel, référent et UTM.
- Ne collecte ni adresse IP dans les données Stats, ni valeur de champ, ni contenu de formulaire, ni chaîne de requête de l'URL.
- Évite le double comptage lorsqu'un ancien script `stats-awm.js` est encore installé manuellement.
- Met en file locale et expédie par lots afin de ne pas ralentir le rendu de la page.
- Dès qu'un Hub Client est jumelé, son `site_id` devient automatiquement une source Stats/Health du client; aucun ajout manuel du site n'est requis.

# 1.11.32 — inventaire Tech à la demande
- Ajoute la route privée `tech/inventory`, authentifiée par le canal de scan Hub Client existant.
- Permet au dashboard Tech côté Alliance de demander immédiatement le profil logiciel complet sans attendre le prochain contact spontané du runtime.
- La route reste invisible côté client et ne transmet aucun secret Alliance ni clé de vulnérabilités.
- Conserve le logo Alliance officiel strictement intact.

# 1.11.31 — contenu long, image Elementor et génération média Tech
- Étend le contexte de texte sélectionné afin que Tech puisse réécrire des paragraphes plus longs sans tronquer prématurément le contenu utile.
- Autorise le réglage `image` uniquement sur les widgets Elementor image et valide l attachment local avant écriture.
- Ajoute le transport privé `tech/generate-image` sur les canaux Connector résilients.
- Le média généré est importé localement et peut être appliqué au widget ciblé avec snapshot et rollback.
- Tech demeure totalement invisible dans le Hub Client.

# 1.11.30 — styles Elementor sécurisés pour Tech
- Étend le moteur privé de modification Elementor utilisé par Tech AWM aux couleurs, fonds, alignements, tailles de police responsive, marges et padding.
- Valide strictement les unités, valeurs, couleurs et types d éléments avant toute écriture.
- Continue de créer un snapshot avant modification et de restaurer automatiquement si le document ou le rendu devient invalide.
- Expose uniquement le sous-ensemble de styles nécessaires à l intervention Alliance; aucun PHP, JavaScript ou CSS arbitraire n est accepté.

# 1.11.29 — handoff Elementor autonome dans Hub Client

- La route privée `tech/intervention/prepare` ne dépend plus du runtime Tech déjà chargé dans la requête courante.
- Hub Client peut valider directement la session auprès d Alliance via le Connector résilient puis créer le handoff Elementor à usage unique.
- Le handoff conserve le même format sécurisé attendu par Tech AWM et reste limité au domaine jumelé, à la page ciblée et à la durée de la session.
- La version Tech réellement présente sur disque est relue avant la redirection et les caches PHP du dossier Tech sont invalidés.
- Si le runtime Tech courant sait déjà préparer Elementor, la délégation normale reste prioritaire; le nouveau mécanisme n est qu un repli déterministe.

# 1.11.28 — auto-réparation propre de Tech AWM

- Ajoute un second passage de réparation propre pour Tech AWM lorsqu une mise à jour distante reste bloquée sur une ancienne version.
- La réparation sauvegarde Tech, désactive le runtime courant, retire uniquement le dossier canonique `tech-awm`, réinstalle le paquet officiel signé, réactive le module puis invalide OPcache.
- Le paquet reste vérifié par SHA-256 et signature Core; aucun autre plugin client n est touché.
- Retourne `success_repaired` et `clean_repair=true` pour que Core puisse distinguer une mise à jour normale d une récupération automatique.
- Futur : ajouter un diagnostic de permissions/fichiers verrouillés avant remplacement afin d éviter même le second passage.

# 1.11.27 — paquet canonique à racine unique

- Corrige uniquement la distribution du module : le ZIP contient maintenant **un seul dossier racine** `hub-client-awm/`.
- Supprime le dossier parasite `hc/` qui faisait refuser le paquet par Core avant installation.
- Conserve la route privée `awm-client-hub/v1/tech/intervention/prepare` et la délégation Tech introduites en 1.11.26.
- Conserve le logo Alliance officiel strictement intact et son SHA-256 canonique.

# 1.11.26 — route Elementor privee toujours disponible

- Deplace le point d entree prive `awm-client-hub/v1/tech/intervention/prepare` sous la responsabilite de Hub Client afin d eviter les 404 lorsque Tech vient d etre mis a jour.
- `update/status` remonte maintenant `tech_prepare_route_ready` en plus de la version runtime Tech reellement chargee.
- La route delegue ensuite la preparation a Tech AWM et retourne une erreur explicite si le runtime Tech n est pas disponible, au lieu de `No route was found`.
- Conserve le logo Alliance canonique strictement intact.

# 1.11.25 — preuve runtime Tech et invalidation PHP

- Après une installation distante, invalide les scripts PHP du module dans OPcache et nettoie le cache des extensions WordPress.
- Désactive les copies actives historiques de Tech AWM ou Hub Client qui pourraient charger un ancien runtime avant le dossier canonique.
- `update/status` retourne maintenant `tech_runtime_version`, soit la constante Tech réellement chargée dans la requête courante.
- Permet à Core de distinguer une version de fichier installée d un runtime PHP réellement actif avant d ouvrir Elementor.
- Conserve le logo Alliance officiel strictement intact.

# 1.11.24 — administration locale épurée

- Retire complètement le grand panneau explicatif **Sécurité** de l’administration locale Hub Client.
- Les protections HTTPS, sessions chiffrées, validation Connector et contrôles de domaine restent actives en arrière-plan; seule leur exposition visuelle côté client est supprimée.
- Confirme la séparation d’architecture : Tech AWM et les détails opérationnels de sécurité sont réservés à Alliance Web Marketing.
- Conserve le provisioning silencieux de Tech AWM et les mécanismes de mise à jour sans ajouter de service ou d’outil Tech au Hub Client.
- Le logo Alliance officiel reste strictement identique au fichier canonique fourni.

# 1.11.23 — Tech AWM devient invisible côté client

- Retire Tech AWM de la navigation, des cartes, des sections et des écrans du portail `/hub/`.
- Une URL historique `?section=tech_awm` est ramenée vers l accueil du Hub.
- Retire la carte Tech de l administration locale Hub Client; le provisioning et la télémétrie restent strictement en arrière-plan.
- Tech AWM demeure installable et maintenable par Alliance, mais n est plus présenté comme un service client.
- Le logo Alliance officiel reste strictement identique au fichier canonique fourni.

# 1.11.22 — télémétrie Connector pour Tech AWM 1.4.3
- Mémorise localement le dernier transport Connector fonctionnel, sa latence et les erreurs récentes, sans stocker le secret.
- Expose à Tech AWM un test contrôlé des quatre transports : REST en-têtes, REST corps HTTPS, admin-ajax et pont frontal.
- Enrichit le profil Tech sécurisé avec le dernier transport, le dernier succès et le dernier événement diagnostic.
- Le logo Alliance officiel reste strictement identique au fichier canonique fourni.

# 1.11.21 — auto-provision du paquet Tech AWM manquant
- Lorsque Tech AWM est **activé par Alliance** mais absent du WordPress client, Hub Client demande à Core l'offre signée du paquet Tech et tente son installation automatiquement.
- Ajoute le bouton **Installer / réparer Tech AWM** dans l'administration Hub Client pour forcer une nouvelle tentative et afficher le diagnostic exact.
- Répare les installations partielles : un dossier `tech-awm` incomplet est sauvegardé en quarantaine puis retiré avant une nouvelle installation propre.
- Accepte les variantes `www` / sans `www` du même domaine Alliance pour le lien HTTPS signé du paquet, sans élargir l'autorisation à un autre domaine.
- Affiche la méthode de système de fichiers lorsqu'un hébergement refuse l'installation distante afin de rendre l'erreur exploitable.
- Le logo Alliance officiel reste strictement inchangé et conserve son SHA-256 canonique `1b0dcbd96e1ed931ce785cda2918e7dc38597c214735e21c92243c02eb43b13a`; le badge Hub orange demeure séparé.

# 1.11.20 — logo Alliance strict dans toutes les sections du Hub Client
- Applique une source de rendu unique du logo Alliance officiel à toutes les sections du portail `/hub/` : Accueil, CallTracker et ses sous-sections, Stats, Tech AWM, Mon compte, Profil, Apparence et Facturation.
- Les écrans de connexion et d’état non lié utilisent exactement le même composant de marque.
- Renforce la protection CSS afin qu’aucun style de module ne puisse filtrer, recolorer, masquer, déformer, recadrer ou redessiner le PNG Alliance.
- Le badge orange Hub demeure un asset distinct superposé et n’altère jamais le fichier du logo.
- Le PNG officiel est recopié octet pour octet depuis le fichier canonique et conserve son SHA-256 `1b0dcbd96e1ed931ce785cda2918e7dc38597c214735e21c92243c02eb43b13a`.

# 1.11.19 — logo Alliance strict et vérifié par empreinte
- Verrouille le logo Alliance officiel avec son SHA-256 canonique `1b0dcbd96e1ed931ce785cda2918e7dc38597c214735e21c92243c02eb43b13a`.
- Ajoute une vérification d'intégrité avant chaque utilisation du logo dans le menu WordPress, le bandeau Hub Client et le portail `/hub/`.
- En cas de fichier absent ou modifié, Hub Client refuse d'afficher une variante : le logo de fond est masqué plutôt que redessiné, recoloré ou remplacé.
- Conserve le badge orange Hub comme asset indépendant superposé, sans modifier le PNG Alliance.
- Ajoute `assets/images/alliance-logo.sha256` comme référence d'intégrité de livraison.

# 1.11.18 — logo Alliance officiel intact sur toutes les surfaces
- Étend l'identité 1.11.17 au portail public `/hub/` : logo Alliance PNG officiel + badge Hub orange séparé.
- Supprime l'ancien SVG composite qui redessinait le logo Alliance afin qu'aucune surface Hub Client ne puisse utiliser une variante du logo.
- Le menu WordPress conserve le logo Alliance original comme icône et ajoute le badge Hub par CSS.
- Le bandeau d'administration et le portail utilisent deux assets superposés sans filtre, recoloration, déformation ni redessin du logo Alliance.
- L'empreinte SHA-256 du PNG Alliance est conservée identique au fichier officiel fourni.

# 1.11.17 — vrai logo Alliance + badge Hub séparé
- Intègre le logo Alliance officiel fourni, pixel pour pixel, dans `assets/images/alliance-logo.png`.
- Le logo Alliance n'est plus redessiné ni recoloré dans l'administration.
- Conserve le pictogramme orange Hub comme badge indépendant superposé au logo.
- Applique cette composition dans l'onglet WordPress Hub et dans le bandeau supérieur à côté du titre Hub.
- Le badge du menu est ajouté en CSS afin que le fichier du logo Alliance reste intact.

# 1.11.16 — logo Hub canonique sans cache
- Remplace toutes les références à l'ancien asset `hub-client-menu-icon.svg` par `hub-awm-product-logo.svg`.
- Le menu WordPress, l'en-tête admin et le portail `/hub/` utilisent tous le même logo Hub AWM avec badge orange.
- Ajoute un versionnement explicite de l'URL du logo pour empêcher l'ancien logo de rester en cache.

## 1.11.15 - 2026-09-05

- Repare les installations Hub Client dupliquees : lors de l activation, la copie 1.11.15 desactive automatiquement les anciennes copies actives du meme module.
- Affiche le runtime et le chemin plugin reel dans l administration locale pour confirmer quelle copie est chargee.
- Force un cache-busting du CSS Premium avec filemtime afin que le nouveau shell ne reste pas masque par un ancien cache navigateur/CDN.
- Conserve les donnees, le Connector, les options et le client_id CRM; aucune re-liaison n est requise.

## 1.11.15 - 2026-09-05
- Hub Client reconnait toujours le plugin qui execute l agent, meme si son dossier historique ne s appelle pas hub-client-awm.
- L inventaire renvoie le vrai plugin_file actif et la version AWM_CLIENT_HUB_VERSION.
- Une mise a jour depuis un ancien dossier migre vers le dossier canonique hub-client-awm avec sauvegarde et reactivation.
- Les prochaines mises a jour distantes ne dependent plus du nom du dossier historique.

# Hub Client AWM 1.11.13 — interface admin Hub Premium

- Utilise le logo produit Hub AWM avec badge orange Hub dans le menu et l'en-tete local.
- Aligne l'ecran Hub Client sur le shell Premium sombre de Hub AWM : cartes, badges, boutons, formulaires et responsive.
- Regroupe l'etat Connector et Tech en donnees compactes; les blocs Relier et Securite deviennent repliables.
- Conserve la liaison CRM canonique, le Connector chiffre et toutes les fonctions existantes.

## 1.11.12 — 2026-09-04
- Ajoute un transport Connector résilient REST en-tête → REST corps HTTPS → admin-ajax.
- Le statut Tech et les échanges Tech utilisent automatiquement le canal disponible.
- Les erreurs finales indiquent les codes HTTP des transports sans exposer le secret.

## 1.11.11 — 2026-09-04
- Renforce le canal de déploiement distant utilisé par Core AWM 4.5.97.
- Accepte le secret de scan dans l'en-tête habituel ou, en repli, dans le corps HTTPS lorsque l'hébergement filtre les en-têtes personnalisés.
- Retourne des erreurs REST explicites pour distinguer Hub non lié, canal non synchronisé et authentification refusée.
- Télécharge les paquets avec un client HTTP sécurisé dédié et rapporte clairement le code HTTP si Alliance refuse le paquet.
- Compatible avec le nouvel endpoint de téléchargement REST signé de Core, sans exposer de chemin serveur ni d'URL permanente de fichier.

## 1.11.10 — 2026-09-04

- Corrige le statut Tech AWM qui pouvait être refusé par certains hébergements malgré une activation Alliance valide.
- Ajoute le transport Connector Tech compatible via le corps HTTPS lorsque les en-têtes personnalisés sont filtrés.
- Répare automatiquement le `client_id` local si Core authentifie le Connector sur une autre fiche CRM canonique.
- Affiche l'identifiant de fiche CRM dans l'administration Hub Client et le client CRM confirmé par Tech.

## 1.11.9 — 2026-09-04
- Le portail `/hub/` utilise maintenant le logo produit Hub AWM canonique, avec la même identité visuelle que Hub AWM; le logo CRM du client ne remplace plus le logo du produit.
- L administration locale Hub utilise le même logo Hub AWM canonique.
- Conserve le nom et le contexte du client à côté du logo sans créer une variante graphique Hub Client.
- Prépare l intégration Tech AWM 1.4.0 avec fenêtre front-end contextuelle et ciblage d URL internes.

## 1.11.8 — 2026-09-04
- Affiche Tech AWM dans la navigation du portail dès que l activation centrale Alliance est active, même avant installation du paquet runtime.
- Ajoute dans l administration Hub Client une carte d état Tech AWM : autorisation Alliance, paquet installé, version et action attendue.
- Si Tech est activé mais absent, le portail affiche une explication plutôt que de masquer silencieusement le module.
- Le statut Tech est lu via le Connector Hub Client existant et mis en cache brièvement; aucun secret supplémentaire n est créé.

## 1.11.7 — 2026-09-04
- Hub Client utilise désormais exactement le même logo Hub AWM que le module Hub, sans badge/variante client.
- L’absence de campagne CallTracker n’est plus traitée comme une erreur Hub Client : CallTracker reste entièrement optionnel.
- Le bloc Réception directe des formulaires affiche un état informatif non bloquant lorsqu’aucune campagne n’existe.
- Le loader d’administration ne transforme plus les alertes passives de sous-modules en fenêtres d’erreur; seuls les résultats explicites d’une action ouvrent le message Premium.

# Changelog Hub Client AWM

## 1.11.6 — 2026-09-04
- Corrige l’erreur critique dans l’administration Hub Client lors du rendu de « Réception directe des formulaires ».
- Le hook `awm_client_hub_admin_after_connection` déclare maintenant explicitement 2 arguments pour `AWM_Client_Hub_Form_Capture::render_admin()`.
- `render_admin()` conserve une valeur de secours pour l’autorisation runtime afin d’éviter une erreur fatale si la méthode est invoquée par une intégration plus ancienne.
- Vérifie les autres consommateurs du même hook : l’agent de mise à jour utilisait déjà correctement 2 arguments.

## 1.11.5 — 2026-09-04
- Extrait le runtime Tech AWM vers le paquet autonome Tech AWM 1.1.0.
- Le portail /hub/ conserve la section Tech AWM lorsque le paquet autonome est actif et autorisé par Alliance.
- Ajoute Tech AWM à l inventaire et au moteur de mises à jour AWM.
- Autorise Core à installer automatiquement Tech AWM lorsqu il est absent, avec SHA-256, activation contrôlée et rollback pour les mises à jour ultérieures.

## 1.11.4 — 2026-09-04

- Intègre **Tech AWM** directement dans Hub Client; aucun plugin ou bridge Tech séparé n est requis.
- Ajoute une section Tech AWM au portail `/hub/` uniquement lorsque Alliance l active dans Thech AWM.
- Ajoute une bulle contextuelle sur les pages WordPress pour discuter, joindre des fichiers, sélectionner un élément Elementor et proposer des modifications.
- Réutilise le Connector Hub Client existant et les routes Studio sécurisées de document/patch/snapshot/restore.
- Sépare les permissions Chat, Diagnostics, Écriture Elementor, Actions WordPress sûres et Fichiers.
- Revérifie l activation Alliance avant toute application ou restauration et refuse une écriture si le hash Elementor a changé depuis l analyse.
- Permet les diagnostics/actions WordPress sûres depuis la section Hub même sans page sélectionnée; les modifications de page exigent un contexte WordPress éditable.

## 1.11.3 — 2026-09-03

- Refonte visuelle **Premium adaptative** de CallTracker → Routage inspirée du modèle 3 validé.
- Tous les contours, halos, fonds, icônes et CTA dérivent automatiquement des couleurs `brand` et `secondary` configurées pour le client; aucune palette bleue fixe n est imposée.
- Ajoute un calcul de contraste pour garder le texte des actions principales lisible même avec une couleur client très claire ou très foncée.
- Agrandit les pictogrammes de campagne, route, horaire, fuseau, délai et destinations avec SVG monochromes pilotés par `currentColor`.
- Renforce la graisse des titres, valeurs et boutons dans le parcours CallTracker sans remplacer les polices choisies par le client.
- Transforme les quatre étapes du funnel en stepper premium relié et rend l étape active beaucoup plus évidente.
- Passe le résumé routage à quatre cartes : route actuelle, état, fuseau et délai de débordement.
- Recompose l horaire en deux tableaux compacts avec en-têtes Jour / Ouverture / Fermeture, tout en conservant le responsive mobile.
- Rend **Enregistrer le routage**, Voir la campagne et Configurer le routage visuellement identifiables comme de vrais boutons dans toutes les palettes client.

## 1.11.2 — 2026-09-03

- Refonte UX de **CallTracker → Routage** pour condenser les réglages sans retirer de fonction.
- Regroupe destinations, fuseau et délai dans une grille compacte à deux rangées.
- Affiche l horaire hebdomadaire sur deux colonnes en bureau afin de réduire fortement la hauteur de page.
- Remplace les champs `time` natifs par des listes d heures 24 h par tranches de 15 minutes pour supprimer le grand sélecteur blanc du navigateur.
- Ajoute un interrupteur compact pour activer l horaire et des blocs distincts pour fermetures spéciales et Message 2.
- Améliore les espacements, tailles de contrôles, responsive et contraste en thème sombre.

## 1.11.1 — 2026-09-03

- Transforme chaque carte **Campagnes** en point d entrée vers une fiche de campagne dédiée.
- Le **nom de la campagne** et son numéro restent visibles dans la liste puis dans l en-tête de la fiche.
- La fiche affiche uniquement les **appels**, **formulaires** et **CPL** de la campagne sélectionnée.
- Ajoute un accès direct au routage de la campagne depuis sa fiche.
- Conserve l isolation stricte : une campagne d un autre client ne peut pas être ouverte par modification de l URL.

## 1.11.0 — 2026-09-02

- Remplace le parcours client centré sur l achat direct par **CallTracker → Nouveaux services → Nouveau funnel → Configuration du numéro → Formulaire/Webhook → Routage**.
- Ajoute **Mes funnels** et **Nouveau funnel** sous Nouveaux services; la liste reflète l état commercial fourni par CRM.
- Étape 1 : le client confirme le Funnel CallTracker à **10 $/mois** et CRM crée le service sans démarrer la facturation tant que le numéro n est pas attribué.
- Étape 2 : recherche, achat et attribution du numéro au funnel déjà créé.
- Étape 3 : webhook du formulaire, copie, test et documentation intégrée.
- Étape 4 : routage complet avec destination principale, fuseau, horaires, jours fermés, destination hors heures, débordement et délai.
- L ancien écran Numéros reste accepté comme alias de compatibilité mais n est plus un onglet principal du CallTracker client.
- Les campagnes existantes renvoient vers l écran Routage dédié au lieu de dupliquer un éditeur simplifié.

## 1.10.2 — 2026-09-02

- Ajoute **CallTracker → Formulaires** dans l espace client.
- Affiche pour chaque funnel son URL de webhook unique avec bouton **Copier**.
- Affiche le dernier formulaire reçu et un bouton **Tester la configuration** sans créer de faux lead.
- Intègre directement la documentation Elementor Pro, Gravity Forms, WPForms et formulaire personnalisé.
- Fournit un exemple JSON et recommande `submission_id` pour améliorer le dédoublonnage.
- Rappelle que l URL du webhook est secrète et doit rester privée.

## 1.10.1 — 2026-09-02

- Ajoute **CallTracker → Numéros** dans le Hub Client.
- Le client peut rechercher un numéro local ou sans frais par pays, indicatif, province/État, ville ou chiffres souhaités.
- Chaque résultat permet de nommer le funnel, confirmer le service à 10 $/mois puis acheter et attribuer le numéro.
- Le Hub n accède jamais aux identifiants Twilio; toutes les recherches et opérations facturables passent par Core AWM.
- L écran est responsive et affiche clairement la formule **1 numéro + 1 formulaire**.

## 1.10.0 — 2026-08-31
- Ajoute les routes privées Studio `page-document`, `update-page-content` et `restore-page-snapshot`.
- Expose à Studio un outline Elementor contrôlé avec IDs et contenu éditable des widgets standards, sans exposer de secret local.
- Applique uniquement des opérations autorisées sur Heading, Text Editor et Button; aucun widget inconnu n est supprimé ni remplacé.
- Autorise l ajout de sections contrôlées à la fin d une page en réutilisant le moteur Elementor local Containers/legacy.
- Crée une sauvegarde avant chaque modification Elementor ou SEOPress, avec empreinte SHA-256 et restauration sécurisée.
- Refuse l écriture si le document Elementor a changé depuis l analyse afin d éviter d écraser une modification concurrente.

## 1.9.5 — 2026-08-27
- Ajoute `/awm-client-hub/v1/studio/publish-page`.
- La publication est limitée aux pages créées par Studio et aux statuts brouillon/en attente/privé.
- Conserve la création initiale en brouillon et les protections SEO existantes.

## 1.9.4 — 2026-08-27
- Ajoute Hero `split` et `image-background` au moteur Studio.
- Ajoute largeur contrôlée 1080/1180/1280/1360 px et échelle typographique responsive.
- Applique réellement l alternance image/texte détectée dans la page de référence.
- Dérive les surfaces sombres/claires depuis la palette du client plutôt que d imposer une couleur générique.
- Conserve Containers, repli Sections/Colonnes, brouillon, noindex et validation du rendu.

## 1.9.3 — 2026-08-27
- Expose la typographie Elementor du site client à Core Studio.
- Applique le profil de design Studio contrôlé aux pages Elementor générées.
- Ajoute effets de survol statiques accessibles et respecte prefers-reduced-motion.

## 1.9.2 — 2026-08-27
- L agent Studio accepte maintenant les modes Photos IA, Photos du client et Mixte.
- Une page peut être créée sans images générées lorsque le mode Photos du client est choisi.
- Le mode Mixte accepte une seule image IA principale; le mode Photos IA conserve l exigence de deux images minimum.
- Le score SEO et le rendu Elementor s adaptent au mode photo sans supprimer les protections de brouillon/noindex.

# Changelog — Hub Client AWM

## 1.9.1 — 2026-08-27
- Ajoute `/awm-client-hub/v1/studio/pages-scan` pour analyser toutes les pages existantes par lots de 100.
- Analyse Elementor ou le contenu WordPress : H1/H2/H3, nombre de mots, images et ALT.
- Lit titre SEO, méta description, mot-clé, canonical, métas sociales et noindex SEOPress.
- Calcule un score SEO pour chaque page et signale les pages système sensibles.
- Ajoute `/awm-client-hub/v1/studio/update-page-seo` pour une révision SEOPress explicite depuis Alliance.
- Refuse la modification des pages système sensibles sans confirmation spécifique.
- Conserve toutes les routes de création, médias et réparation Studio 1.9.0.

## 1.9.0 — 2026-08-27
- Détecte SEOPress et SEOPress Pro dans l’état Studio du site.
- Reçoit au moins deux images générées par Core et les enregistre localement dans la médiathèque.
- Nomme les fichiers `nom-de-la-page-0001.jpg`, `-0002.jpg` et suivants.
- Définit `0001` comme image mise en avant et renseigne titre, ALT et description des médias.
- Intègre la première image dans le Hero et la deuxième dans le contenu Elementor.
- Configure les métadonnées SEOPress et maintient noindex sur le brouillon; noindex est retiré à la publication.
- Retourne un score SEO Studio et les informations médias à Hub.


## 1.8.9 — 2026-08-27
- Corrige la génération Studio pouvant produire une page Elementor blanche.
- Ajoute `isInner` à tous les widgets générés conformément à la structure Elementor.
- Détecte l activation réelle des Flexbox Containers.
- Génère automatiquement une structure legacy Section / Colonne / Widget lorsque Containers n est pas disponible.
- Valide le JSON enregistré, le nombre d éléments et le rendu frontend avant de retourner un succès.
- Retente automatiquement en Sections/Colonnes si un rendu Containers est vide.
- Ajoute `/awm-client-hub/v1/studio/repair-page` pour réparer uniquement les brouillons Studio existants.
- Conserve la publication directe bloquée et les secrets hors du site client.

## 1.8.8 — 2026-08-27
- Ajoute l’agent local privé **Studio AWM**.
- Ajoute `/awm-client-hub/v1/studio/status` pour analyser Elementor, Elementor Pro, thème, WordPress, PHP, logo et palette.
- Ajoute `/awm-client-hub/v1/studio/create-page` pour créer uniquement des brouillons WordPress/Elementor.
- Réutilise le secret de commande Hub Client 256 bits déjà synchronisé avec Core; aucune nouvelle clé n’est exposée.
- Rend les commandes de création idempotentes par identifiant de requête.
- Reconstruit localement les widgets Elementor depuis une liste de sections autorisées; aucun PHP, JavaScript ou HTML arbitraire du brief n’est exécuté.
- Conserve les fonctions portail, CallTracker, Stats, Facturation, profil, apparence et mises à jour existantes.

---

## 1.8.7 — 2026-08-25

- Ajoute la lecture des enregistrements CallTracker par proxy local de session.
- Ne reçoit plus d URL Twilio brute dans le contrat client.
- Utilise Core pour vérifier la propriété puis récupérer le média avec les secrets conservés côté Alliance.
- Ajoute un contrôle audio dans Appels uniquement lorsqu un enregistrement autorisé existe.
- Affiche les appels dans le fuseau de leur campagne à partir de la date UTC canonique.
- Conserve l état CPL en validation et les contrôles fail-closed de 1.8.6.

---

## 1.8.6 — 2026-08-25

- Affiche un état **CPL en validation** lorsque des campagnes CallTracker du client ne sont pas encore approuvées.
- Indique le nombre de campagnes approuvées par rapport au total sans exposer les détails administratifs internes.
- Masque les lignes CPL des campagnes en attente et n’affiche jamais les données d’une autre campagne comme remplacement.
- Conserve les campagnes, appels, formulaires et Dialer accessibles selon les services et permissions existants.
- Remplace les confirmations navigateur natives de suppression du Message 2 et d’une attribution de formulaire par des confirmations AWM intégrées avec contrôle serveur.
- Exige Core AWM 4.5.39 et CallTracker AWM 1.9.2 pour la validation complète.

---

## 1.8.5 — 2026-08-24

- Mon compte → Facturation affiche maintenant les avoirs appliqués aux factures natives CRM.
- Le solde visible tient compte des paiements et des crédits.
- Ajoute les statuts Réglée et Créditée à l’affichage client.
- Le résumé de facturation distingue le total des avoirs et regroupe les factures soldées.
- Une facture sans solde n’affiche plus d’action de paiement.
- Aucun détail du grand livre interne ni aucune donnée sensible de paiement n’est exposé au portail.

---

# Changelog — Hub Client AWM

## 1.8.4 — 2026-08-24

- Remplace les bandeaux `.awm-alert` de l’administration Hub par un loader local.
- Supprime aussi les notices réseau/utilisateur WordPress et les update nags sur la page Hub.
- Conserve les erreurs importantes ouvertes jusqu’à fermeture; les succès disparaissent automatiquement.
- Aucun changement au Connector, aux sessions, à la facturation ou au Dialer.

## 1.8.3 — 2026-08-24

- Ajoute sur `/hub/` deux modes clairement séparés : **Connexion Alliance** et **Compte WordPress autorisé**.
- Permet de saisir directement un identifiant/courriel et un mot de passe WordPress sur `/hub/`; le mot de passe est validé localement par WordPress et n’est jamais transmis à Alliance.
- Après authentification locale, Core vérifie toujours que la référence cryptographique du compte fait partie des utilisateurs explicitement autorisés dans la fiche client.
- Conserve le bouton de continuation pour un utilisateur WordPress déjà connecté.
- Remplace l’icône visible du menu `Hub` par la base graphique AWM officielle utilisée par les autres modules, avec un petit badge portail/client.
- Conserve les dimensions 20 × 20 px et l’alignement WordPress.
- Aucun changement de Connector, session, facturation, Dialer ou données client.

## 1.8.2 — 2026-08-24

- Corrige la taille de l’icône **Hub** dans le menu WordPress du site client.
- Force l’icône AWM à 20 × 20 px dans le menu afin de l’aligner sur les autres entrées WordPress.
- Conserve le libellé visible **Hub** côté client et l’identité technique **Hub Client AWM** dans Core/diagnostics.
- Aucun changement des sessions, du Connector, de la facturation, du Dialer ou des données métier.

---

## 1.8.1 — 2026-08-24

- Déplace **Facturation** dans **Mon compte → Facturation**; elle n’est plus présentée comme un module CRM client.
- Retire le module interne `crm_awm` de la navigation et des cartes de services du Hub côté client.
- La facturation du compte Alliance reste disponible indépendamment de l’activation d’un éventuel service CRM destiné aux propres clients du client.
- Ajoute au sous-onglet Facturation le résumé du solde, des factures à payer, en retard et payées.
- Conserve le paiement sécurisé via SSO WHMCS sans faire transiter de numéro de carte ni de CVV dans AWM.

---

## 1.7.0 — 2026-08-24

- Présente le module côté WordPress client simplement sous le nom visible **Hub** avec une icône AWM dédiée.
- Refonte le Dialer CallTracker sur le modèle administrateur : campagne, grand numéro, clavier 1–9/*/0/#, activation micro, appel, raccrochage, effacement et états Twilio.
- Ajoute DTMF pendant un appel lorsque le SDK Twilio le permet.
- Ajoute dans Campagnes la modification du numéro de réception et la gestion du Message 2 publicitaire.
- Permet au client de téléverser/remplacer/supprimer un MP3 Message 2 de 5 Mo maximum; le contenu reste stocké chez Alliance.
- Affiche Message 1 en lecture seule, sous contrôle Alliance.
- Affiche les appels sortants comme **Sortant** et rappelle qu’ils sont exclus des leads/CPL.
- Conserve le Connector, sessions, agent de mise à jour et personnalisation existants.

---

# Changelog

## 1.6.1 — 2026-08-24
- Premier test reel du deploiement distant Core → Hub Client.
- Force le bootstrap du secret de commande distante lorsque 1.6.0 a ete installe manuellement mais que Core ne l'a pas encore recu.
- La route locale de diagnostic indique maintenant explicitement si l'agent est pret.
- Aucun changement des sessions, du Connector, de Profil/Apparence ou des donnees client.
 — Hub Client AWM

## 1.6.0 — 2026-08-24

- Ajoute l’agent local de mises à jour AWM pilotable depuis Core sans connexion manuelle à wp-admin.
- Expose les endpoints privés `/awm-client-hub/v1/update/status`, `/update/apply` et `/update/rollback`, authentifiés avec le secret 256 bits déjà utilisé par le Connector.
- Synchronise l’inventaire des modules AWM installés, leurs versions et leur état actif/inactif vers Core.
- Vérifie que chaque commande provient de la plateforme Alliance liée, exige HTTPS, valide la signature HMAC et le SHA-256 du ZIP avant installation.
- Exécute l’installation avec les API WordPress locales seulement lorsque le système de fichiers est disponible en mode `direct`.
- Sauvegarde le dossier du module avant remplacement, conserve jusqu’à trois sauvegardes par module et restaure automatiquement en cas d’échec ou de version inattendue.
- Intègre aussi les publications Core au système natif de mises à jour WordPress comme voie de secours.
- Aucune donnée métier, session, Connector ou personnalisation client n’est supprimée par une mise à jour de fichiers.

---
## Historique conservé

## 1.5.0 — 2026-08-24

- Synchronise un annuaire minimal des utilisateurs WordPress vers Core AWM afin qu’Alliance puisse les autoriser depuis la fiche client.
- L’accès local à `/hub/` n’est plus accordé simplement parce qu’un compte possède `manage_options`; Core exige maintenant une autorisation explicite du compte scanné.
- Ajoute un callback privé de scan protégé par un secret aléatoire chiffré localement et dans le coffre Core.
- Synchronise aussi l’annuaire après création, modification, changement de rôle ou suppression d’un utilisateur.
- Corrige le sélecteur de couleur d’Apparence : le champ perd son focus après sélection et la molette retrouve immédiatement le défilement vertical.
- Conserve la liaison Hub Connector existante, les sessions chiffrées, le portail modulaire et les données métier chez Alliance.

---
## Historique conservé

# Changelog — Hub Client AWM

## 1.4.0 — 2026-08-23

- Transforme `/hub/` en portail **modulaire** : Accueil, CallTracker, Stats et Mon compte sont séparés en onglets de premier niveau.
- Regroupe Campagnes, Leads, Appels, CPL et Dialer dans le module CallTracker avec une sous-navigation dédiée.
- Stats AWM devient un module distinct et n’apparaît que lorsqu’il est activé pour le client.
- La navigation utilise le registre des services renvoyé par Core; un module non attribué au client n’est ni présenté ni ouvert par le portail.
- Ajoute un accueil par cartes de services actifs avec accès direct aux modules.
- Améliore le responsive téléphone/tablette : onglets défilables, cartes en une colonne, KPI adaptatifs et tableaux Leads/Appels/CPL convertis en cartes lisibles sur petit écran.
- Conserve Profil et Apparence dans un groupe Mon compte distinct des modules métier.
- Conserve la liaison Connector, la session chiffrée, le Dialer et les données historiques sans changement d’identifiant ni de stockage.

---
## Historique conservé

## 1.3.0 — 2026-08-23

- Ajoute l’onglet **Profil** dans `/hub/` pour modifier le nom affiché et la fonction du client.
- Le profil d’affichage reste séparé du nom canonique, du courriel et des données de facturation CRM/WHMCS.
- Ajoute l’onglet **Apparence** pour personnaliser les couleurs, polices et graisses du portail et de la page de connexion.
- Les valeurs sont envoyées à Alliance par la session Hub chiffrée; Core revalide le client et journalise chaque écriture.
- Les polices sont limitées à une liste autorisée et aucun CSS arbitraire n’est accepté.
- Un instantané local non sensible du profil et du style permet de personnaliser la page de connexion avant authentification; le jeton Alliance reste côté serveur.
- Les instantanés sont rafraîchis lors de la liaison, de la connexion, de l’accès administrateur et après chaque modification.
- Ajoute les styles responsive requis pour les formulaires Profil et Apparence.
- Conserve CPL, Dialer, campagnes, formulaires directs et toutes les protections Hub Connector 1.2.0.
---
## Historique des versions précédentes

## 1.1.1 — 2026-08-18
- Ajoute l’onglet Dialer directement dans `/hub/` avec sélection de campagne, microphone, appel et raccrochage.
- Le SDK Twilio Voice est livré localement avec l’extension; aucun CDN tiers n’est requis pour charger le Dialer.
[Ligne masquée automatiquement par Core AWM : contenu sensible potentiel]
- La vue Campagnes consomme la résolution canonique Core 4.5.4 et peut donc retrouver les anciennes campagnes sûres du même client.
- Le message vide parle désormais de campagne « liée » plutôt que seulement de campagne « active », puisque les campagnes publiées inactives restent visibles.

## 1.1.0 — 2026-08-18
- Corrige le cas « Identifiants invalides » pour les administrateurs : le formulaire distingue maintenant compte Alliance et accès administrateur du WordPress local.
- Ajoute une session administrateur locale déléguée au client lié, vérifiée par Core via l’autorisation runtime du Connector.
- Le Connector runtime est chiffré au repos sur le WordPress client; le code de pairing est à usage unique.
- Les administrateurs Alliance peuvent se connecter avec leur compte central tout en restant limités au client associé à ce domaine.


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

- Hub Client AWM 1.0.1 chiffre la totalité de la session locale côté serveur, lie la session au navigateur et exige HTTPS vers Alliance; aucune donnée Alliance exploitable n’est persistée en clair sur le site client.
# Changelog — Hub Client AWM

## 1.0.0 — 2026-08-17
- Première version installable sur le WordPress du client.
- Point d'entrée public `/hub/` sans création obligatoire d'une page WordPress.
- Liaison sécurisée par code Hub Connector généré dans la fiche client Alliance.
- Connexion distante au compte client Alliance sans stockage du mot de passe.
- Session locale HttpOnly avec jeton Alliance chiffré côté serveur.
- Vérification stricte que le compte connecté correspond au client lié au domaine.
- Vue responsive clair/sombre avec mémorisation du thème avant rendu.
- Identité visuelle client issue du profil Alliance lorsque disponible.
- Vues Vue d'ensemble, Campagnes, Leads, Appels et Stats AWM.
- Masquage des notices WordPress/tiers sur la page d'administration du module.

## 1.8.0 — 2026-08-24
- Ajout du module CRM avec sous-onglet Facturation.
- Affichage des factures, soldes, échéances, taxes et lignes de facture du client connecté.
- Bouton Payer maintenant utilisant un SSO WHMCS à usage unique; aucune donnée de carte n’est traitée par Hub.


---

## README.md

# Hub Client AWM 1.14.44

Suite AWM 4.5.470 — Identité de l’en-tête client · 22 octobre 2026.

Hub Client 1.14.44 affiche le logo client seul dans le bloc de marque; à défaut, favicon et noms de compagnie/utilisateur; à défaut, logo AWM et ces noms. Les images défaillantes passent au repli suivant. Le rendu garde proportions, accessibilité et largeur mobile, sans changer les préférences d’apparence.

Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.470.md. Les vérifications locales du code et du navigateur ne constituent pas une installation WordPress ni une validation sur le site de production.

---

# Hub Client AWM 1.14.43

Suite AWM 4.5.469 — Aperçu avant enregistrement · 22 octobre 2026.

Deux démonstrations clair/sombre réagissent immédiatement aux choix du formulaire avec le CSS réel du portail : carte, H1/H2/H3, texte, boutons, champ, badge et indicateur. Neutral propose les détails de cinq rôles, les polices détectées ou en bibliothèque et les poids contrôlés 100..900; les recettes nommées restent complètes. Les modifications restent locales jusqu’à Enregistrer les deux profils; la bascule du haut conserve son comportement.

Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.469.md. Les essais utilisent le code PHP/CSS/JavaScript réel avec services WordPress substitués; ils ne valent pas installation ou validation sur le site de production.

---

# Version 1.14.42

Suite AWM 4.5.468 — Bascule clair/sombre et profils distincts.

Le bouton ◐ connecté est de nouveau une vraie bascule : changement immédiat, enregistrement authentifié du mode seul, retour visible en cas d’erreur et formulaire de repli sans JavaScript. Apparence présente Paramètres clairs et Paramètres sombres, chacun avec les six axes du catalogue et cinq couleurs de surface. Les polices Neutral, leurs graisses et la couleur secondaire sont explicitement communes. Les éditions en cours restent intactes pendant une bascule.

Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.468.md. Aucune installation ni publication de cette version sur l’hébergement n’est présumée.

---

# Hub Client AWM 1.14.41

Le formulaire existant propose Automatique · logo puis site, Toujours sombre et Toujours clair. Son aide explique la mémorisation du choix et sa priorité sur l’analyse automatique. Les contrôles de persistance utilisent le vrai formulaire, le handler du portail et le callback Core, avec transport et stockage de test. Le choix du portail reste indépendant du mode administratif.

## Validation et portée

Cette version fait partie de Suite AWM 4.5.466. Les preuves détaillées sont dans `PREUVES-VALIDATION-SUITE-AWM-4.5.466.json` et le rapport `VALIDATION-SUITE-AWM-4.5.466.md` de la Suite. Elles couvrent le rendu PHP et Chromium, les modes opposés, les bascules, les identités distinctes et la persistance du choix du portail. Les tests s’exécutent localement avec données et services WordPress substitués; ils ne constituent pas une installation sur le site de production.

Les préférences client ne sont pas modifiées par l’ouverture d’une carte ou d’une fiche administrative, ni par une bascule Core. Les anciennes notes ci-dessous restent historiques : pour cette livraison, les cartes et fiches administratives utilisent la variante Core, tandis que Hub Client conserve son choix indépendant.

---

## Mise à jour 1.14.40 — 2026-10-22 · Suite 4.5.464

Le portail consomme désormais l’apparence client canonique, indépendante du thème administratif Core. Le profil partagé expose `design.color_scheme` (`auto`, `light`, `dark`) et `design.resolved_color_scheme` (`light`, `dark`). En automatique, le choix provient de l’identité du logo/site : un logo sombre donne le thème sombre, un logo clair le thème clair.

Le profil automatique reste un point de départ. Le client peut toujours personnaliser son thème et choisir Clair/Sombre manuellement; ses préférences explicites gardent leur priorité. Le retour à l’automatique reste disponible comme action explicite. Le portail conserve le catalogue partagé et les six axes existants, sans reconstruire le CSS du site ni créer une autre identité.

Le portail lit le profil `/me` avant de produire le `head`, puis réutilise cette réponse dans Profil et Apparence. Si l’API est indisponible, le snapshot existant sert de repli. Le mode canonique est donc appliqué dès le document serveur.

La sérialisation des piles de polices est corrigée dans CRM et le portail : les 33 variables sont assemblées dans un attribut `style` échappé une seule fois. Les guillemets des noms de police restent du CSS valide; les séparateurs de déclaration et les caractères de contrôle sont refusés. Cela évite les entités HTML littérales dans les valeurs CSS et le repli involontaire vers une autre police. Le sérialiseur conserve chaque famille d’une pile compilée séparément et laisse les familles génériques, telles que `system-ui`, `ui-monospace` et `serif`, sans guillemets; une pile entière n’est plus traitée comme un seul nom de police.

Les réglages de densité existants **Compact, Standard et Confortable** sont réellement appliqués au portail et à la fiche CRM. Les anciennes valeurs fixes du `body` du portail et des alias CRM ne masquent plus les tokens partagés : `--hub-gap`, `--hub-panel-pad`, `--hub-control-height` et `--hub-cell-padding`. Espacement, panneaux, hauteur des champs et cellules de tableau suivent le profil choisi. Le catalogue et les autres axes restent inchangés.

Les résultats locaux de 1.14.40 sont consignés dans les rapports de Suite 4.5.464. Ils ne constituent ni une installation sur l’hébergement actuel ni une publication publique. Les entrées précédentes ci-dessous sont conservées comme historique.

La précision finale porte sur les six choix existants : Style, Couleur, Typographie, Surface, Mouvement et Densité. En automatique, Hub rapproche chaque indice exploitable du CSS du site des options du catalogue. Neutral, Auto, Subtle et Standard sont les replis respectifs de typographie, surface, mouvement et densité lorsqu’aucun indice exploitable n’existe, notamment pour un logo seul. Les choix manuels restent prioritaires.


## Mise à jour 1.14.39 — 2026-10-21
- L écran Apparence consomme le catalogue Design Composer reçu de Core/Hub AWM au lieu de maintenir un catalogue figé.
- Le client voit la source de son thème recommandé et peut personnaliser famille, couleur, typographie, surface, mouvement et densité.
- Le bouton de réinitialisation devient `Revenir au thème automatique · logo -> site -> AWM`.
- Les tokens compilés par Core sont prioritaires pour géométrie, typographie, surfaces, mouvement et rythme du portail.
- Le même profil visuel est appliqué aux vues Accueil, CRM, Stats, LeadTracker/CallTracker, Soutien, Assistant et futurs services compatibles rendus dans le portail.
- `prefers-reduced-motion` reste prioritaire.

## Hub Client AWM 1.14.38 - Surface & Mouvement v2
Hub Client applique les 12 surfaces et 12 mouvements du Design Composer au portail et aux pages Studio, avec parité Light/Dark et respect de `prefers-reduced-motion`.

## Hub Client AWM 1.14.37 - Design Composer Studio page-scoped
Le Hub Client peut maintenant recevoir de Studio un `design_profile` et des `design_tokens` compilés par Core, puis les appliquer à la page Elementor créée. Les nouveaux effets restent soumis à `prefers-reduced-motion`. Le portail conserve son runtime visuel autonome et le kit global Elementor existant n est pas muté automatiquement.

## Hub Client AWM 1.14.35 - Profil design client
Le portail applique le contrat de design client fourni par Hub : famille, accent et densite, avec Light/Dark independant. Il conserve les garde-fous de contraste et ne charge pas le CSS administratif central.

## 2026-10-20 - Hub Client AWM 1.14.34
Le miroir local/confidentialite normalise maintenant l identite VMV avec le meme contrat que LeadTracker 1.11.75. Le chemin normal reste central-owned : LeadTracker cree le contact, Hub Client complete seulement les donnees locales lorsque requis.

## 2026-10-18 - Hub Client AWM 1.14.33 - mappings de campagne actifs auto-appliqués

- Hub Client ne dépend plus d’un clic administrateur pour appliquer les mappings d’une campagne active.
- Un worker local actualise les campagnes/mappings Alliance toutes les cinq minutes et remplace automatiquement les associations gérées par Alliance; une campagne mise en pause disparaît donc du routage géré lors de la prochaine synchronisation.
- Chaque vraie soumission Elementor, Gravity Forms, Contact Form 7 ou hook AWM force en plus une lecture fraîche de `forms/campaigns` avant de résoudre la route. Une campagne activée ou modifiée quelques secondes auparavant ne peut plus être masquée par le cache de cinq minutes.
- Les mappings explicites restent prioritaires et VMV-NAT conserve son fallback `capturia_auto_all_forms`.
- Aucune soumission historique n’est rejouée par ce worker; il ne fait que synchroniser la configuration de routage.

## 2026-10-18 - Hub Client AWM 1.14.32 - complément données du moteur Capturia central

- Quand LeadTracker indique `central_owned=1`, Hub Client ne crée plus de contact Capturia et ne retague pas Google.
- Si le mode confidentialité local est actif, LeadTracker retourne le contact Capturia exact et un reçu technique lié au `local_ref`; Hub Client ajoute uniquement les notes complètes depuis le miroir local chiffré.
- Le complément utilise les mêmes clés d'idempotence et la même preuve centrale; aucun doublon de contact n'est créé.
- Le chemin normal sans mode confidentialité est entièrement pris en charge par LeadTracker et Hub Client reste passif.

## 2026-10-16 - Hub Client 1.14.31 / Suite AWM 4.5.424 - Capturia immédiat sur le lead exact

- Corrige la file FIFO du chemin de capture : un nouveau formulaire ne peut plus être bloqué derrière d'anciens `pending/retry`. `process_queue('capture')` traite maintenant le `local_ref` exact qui vient d'entrer.
- Dès que LeadTracker retourne son `form_row_id`, Hub Client envoie immédiatement un reçu technique `En attente` sans PII. La ligne ne doit donc plus rester silencieusement `Sans preuve` pendant la préparation Capturia.
- Le flux normal est synchrone : formulaire réel → LeadTracker → Capturia contact → étiquette Google → toutes les notes/données → reçu `accepted`, dans la même requête.
- Les notes multiples ne sont plus espacées de 15 secondes en fonctionnement normal; tous les blocs sont envoyés immédiatement. Seuls HTTP 429, erreur réseau incertaine ou refus API arrêtent le flux et déclenchent la reprise sûre.
- Les clés d'idempotence restent inchangées et une réponse mutative incertaine n'est jamais rejouée aveuglément. Aucun historique n'est relancé automatiquement.

## 2026-10-16 - Hub Client 1.14.30 / Suite AWM 4.5.420 - Capturia déclenché par la réponse autoritaire du lead

- Corrige le défaut terrain persistant où un lead VMV-NAT entrait dans LeadTracker mais restait `Sans preuve` sans jamais atteindre la file Capturia.
- Le flux ne dépend plus d'une seconde lecture de `forms/campaigns` après la capture. LeadTracker retourne avec `forms/submit` une instruction PII-free pour la campagne exacte; Hub Client l'utilise immédiatement.
- Séquence normale : miroir local chiffré → `forms/submit` → instruction Capturia autoritaire → file idempotente locale → création contact → étiquette Google → données → reçu technique LeadTracker, dans le même traitement.
- Si la clé, les scopes, l'étiquette ou le Connector empêchent l'envoi, la ligne locale passe en reprise contrôlée et une preuve technique peut remonter; elle ne doit plus rester silencieusement `Sans preuve`.
- Le cron n'est qu'un secours. Aucun des historiques 563 n'est rejoué et une réponse réseau incertaine n'est jamais renvoyée aveuglément.

## 2026-10-16 - 1.14.29 / Suite AWM 4.5.419 - Capturia immédiat sans relecture de cache au verrou final

- Corrige le défaut terrain de 1.14.28 : `on_form_captured()` lisait bien VMV-NAT en mode frais, mais `enabled()` puis `process_queue()` pouvaient relire aussitôt le cache précédent et interrompre l'envoi.
- Le chemin de capture force désormais le contrat frais de bout en bout (`target(true)`, `enabled(true)`, `process_queue('capture')`) avant toute écriture Capturia.
- Tout nouveau formulaire VMV admissible est mis en file idempotente et traité immédiatement dans la même requête. Le cron reste uniquement une reprise contrôlée sur erreur/rate-limit.
- Les mappings explicites vers une autre campagne restent prioritaires; aucun historique n'est rejoué automatiquement et les réponses réseau incertaines restent non rejouées aveuglément.

## 2026-10-16 - 1.14.28 / Suite AWM 4.5.418 - Capturia immédiat sans cache périmé

- Force une lecture fraîche du contrat VMV-NAT/Capturia au moment de chaque capture afin qu'un cache de campagne antérieur à `capturia_auto_all_forms` ne puisse plus faire sauter silencieusement l'envoi.
- Garantit la création/présence de la file Capturia même si le miroir chiffré possède déjà la soumission; l'idempotence est conservée par `local_ref`.
- Après une capture admissible, la file est traitée immédiatement; les crons restent uniquement des reprises contrôlées.
- Aucun historique n'est rejoué automatiquement et une livraison incertaine n'est jamais relancée aveuglément.

## 2026-10-15 - 1.14.27 / Suite AWM 4.5.416 - Capturia immédiat à la soumission

- Tout nouveau formulaire VMV admissible est envoyé à Capturia immédiatement dans le même flux que sa capture locale; aucun délai normal de 36 h, 65 s ou cron n'est requis.
- La file locale reste la source idempotente et ne sert qu'à une reprise contrôlée si Capturia, la clé ou le réseau sont momentanément indisponibles.
- Une réponse réseau incertaine reste en état `uncertain` et n'est jamais rejouée aveuglément.
- L'association explicite à une autre campagne reste prioritaire; VMV-GADS, VMV-FADS, VMV-YT et les autres campagnes ne sont pas déplacées vers VMV-NAT.
- Aucun historique n'est relancé automatiquement. Le mécanisme de rattrapage 36 h des versions précédentes n'est plus exécuté par 1.14.27.

## 2026-10-15 - 1.14.26 / Suite AWM 4.5.415 - VMV-NAT Capturia automatique pour tous les formulaires

- Quand la destination Capturia est active sur VMV-NAT, tout formulaire capturé sur le WordPress principal de Vendre Maison Vite est automatiquement attribué à VMV-NAT et mis en file Capturia, sans exiger une sélection manuelle formulaire par formulaire.
- Une association explicite du formulaire à une autre campagne reste prioritaire : VMV-GADS, VMV-FADS, VMV-YT et toute autre campagne ne sont jamais déplacés silencieusement vers VMV-NAT.
- Elementor, Gravity Forms, Contact Form 7 et le hook générique Hub Client suivent le même contrat. Les moteurs futurs qui passent par le hook générique héritent automatiquement du routage.
- Le rattrapage récent 36 h est versionné à nouveau afin de mettre en file les captures VMV-NAT récentes sans livraison locale, sans rejouer les 563 historiques et sans dupliquer une ligne déjà livrée.
- Capturia reçoit toutes les données métier utiles du formulaire; la preuve renvoyée à Alliance reste strictement PII-free.

## 2026-10-15 - 1.14.25 / Suite AWM 4.5.413 - Capturia multi-formulaires et rattrapage recent cible

- Corrige le routeur Capturia VMV-NAT qui etait encore limite a `hub_client_elementor` dans 1.14.24. Les formulaires explicitement mappes Elementor, Gravity Forms et Contact Form 7 suivent maintenant le meme circuit Capturia.
- Chaque capture calcule un `submitted_at_utc` canonique. Gravity Forms `date_created` est interprete comme UTC; les autres sources historiques sont converties depuis le fuseau WordPress vers UTC.
- Le recu de preuve PII-free ajoute source, identifiant de formulaire, phase et curseur de notes afin que LeadTracker affiche les etapes de livraison.
- A la premiere synchronisation 1.14.25, un rattrapage borne aux 36 dernieres heures inspecte le miroir local chiffre, resoumet les formulaires au registre central avec leur identifiant stable, puis met en file Capturia uniquement les lignes qui n ont jamais eu de livraison locale.
- Ce rattrapage est idempotent, ne rejoue jamais le backfill historique des 563 lignes et ne cree pas une deuxieme ligne Capturia lorsqu une livraison locale existe deja.
- Aucun envoi fournisseur n est execute pendant l installation elle-meme; le worker reste asynchrone et respecte les pauses HTTP 429.

## 2026-10-15 - 1.14.24 / Suite AWM 4.5.410 - VMV-NAT : données CRM complètes et identité visible

- Capturia demeure le CRM du client Vendre Maison Vite : le contact reçoit le nom, le courriel et le téléphone structurés, puis **toutes les réponses utiles du formulaire Elementor** sont conservées dans une ou plusieurs notes Capturia.
- Les champs techniques sensibles (mot de passe, jeton, nonce, captcha, clé API, carte/CVV) sont volontairement exclus du transfert CRM.
- Si les réponses dépassent une note, Hub Client les découpe en notes idempotentes et reprend automatiquement après HTTP 429 sans perdre les parties déjà acceptées.
- Le transport `local_mirror_v1` transmet désormais à LeadTracker uniquement l identité opérationnelle minimale (nom, courriel, téléphone) afin que la liste affiche le vrai contact; le reste du formulaire demeure dans le miroir local chiffré et dans Capturia.
- La table de **preuve Capturia** reste strictement sans PII : identifiants techniques, statut, HTTP/request ID et horodatage seulement.
- Aucun envoi n est déclenché par l installation; le routage reste limité au site principal Vendre Maison Vite et à VMV-NAT.

## 2026-10-15 - 1.14.23 / Suite AWM 4.5.409 - Capturia : preuve de livraison des nouveaux formulaires

- Après l enregistrement central du formulaire, le Hub Client rattache l identifiant technique AWM à la file locale Capturia et renvoie à Alliance un reçu **sans PII** après chaque changement d état.
- Le reçu contient uniquement les identifiants techniques, l état, le code HTTP, l identifiant de requête et l horodatage; aucun nom, téléphone, courriel ni contenu de formulaire n est renvoyé pour cette preuve.
- Les nouveaux envois VMV-NAT respectent `Retry-After` / `RateLimit-Reset`, n utilisent plus une limite fixe de quatre essais sur HTTP 429 et ne traitent qu une ligne Capturia par passage afin de réduire les nouvelles limites API.
- Le prochain passage est replanifié automatiquement lorsqu une ligne reste à envoyer. Les clés d idempotence existantes sont conservées.
- AWM n appelle aucune fonction SMS/courriel Capturia. Les automatisations éventuellement configurées dans le compte Capturia restent hors du contrôle d AWM.
- Aucun formulaire n est envoyé à l installation; la route reste strictement limitée au site principal Vendre Maison Vite et à VMV-NAT.

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

Registre local CRM multicanal avec transactions, charges nominatives chiffrees par Core, index tenant-scopes, endpoints prives et vue du portail CRM.

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.

---

# Vendre Maison Vite — Capturia sortant (1.14.21)

Depuis LeadTracker AWM central : activer la destination Capturia Google sur VMV-NAT (source CPL SEO, campagne active et formulaire Elementor du site principal rattaché). Hub Client appairé récupère **la clé API existante** par Core Connector (aucun nouveau champ), vérifie contacts:write, tags:read et la présence de l'étiquette Google. Queue locale chiffrée avec idempotence ; aucune émission SMS ni backfill vers Capturia. Suivi sur Hub Client → Vendre Maison Vite — Capturia. À confirmer en production.

## 1.14.20 — Protection du contenu Elementor
Une valeur lue avec `get_post_meta(..., '_elementor_data', true)` est déjà déséchappée par WordPress au niveau SQL : ne JAMAIS appliquer `wp_unslash()` sur la chaîne JSON; cette fonction ne sert qu'aux données de requête `$_POST`/`$_GET`. La version 1.14.20 sauvegarde le JSON d'origine avant écriture, vérifie l'isolation de chaque modification et s'arrête sur les signatures de corruption historique. Voir le guide Suite AWM 4.5.391.

# Hub Client AWM 1.14.19 — Bouclier local Elementor avant courriels
La protection AWM s'exécute sur **chaque WordPress client** dans `elementor_pro/forms/validation` (priorité 1), **avant toute action Elementor** : envoi au client, Email2, webhook, stockage Elementor, CRM, LeadTracker ou tout autre traitement qui suit la validation. Un rejet appelle `Ajax_Handler::add_error` et bloque l'exécution normale des actions.

## Protection disponible
- **Standard par défaut** : blocage des signaux forts (piège invisible rempli, URL en rafale, requêtes répétées, email invalide combiné à une soumission sans preuve navigateur). Les formulaires légitimes restent possibles si le service de preuve JavaScript est indisponible.
- **Surveillance** : consigne un blocage hypothétique sans interrompre l'envoi. **Strict** : exige une preuve HMAC émise par le site et bloque les signaux de risque renforcés. **Désactivé** : pas de contrôle.
- Les pages mises en cache reçoivent leur défi signé via AJAX local; aucune dépendance à un service externe ni transfert du texte des prospects.
- Journaux locaux **sans PII en clair** : horodatage, identifiant de formulaire haché, raisons, score et compteurs. Traces bornées à 150 événements.
- Une commande Tech AWM authentifiée et liée au site (`/tech/form-guard/policy`) applique le niveau voulu, et `/tech/form-guard/status` confirme le site, l'instance, le mode et les compteurs.

## Installation et précautions
1. Mettre à niveau Hub Client AWM 1.14.19 sur le WordPress client.
2. Vérifier une vraie soumission Elementor : le client doit recevoir son courriel et LeadTracker doit continuer à capter le lead.
3. Tester un piège rempli ou une soumission répétée : **aucun courriel au client** et **aucune copie LeadTracker** ne doit partir.
4. Piloter la flotte depuis Tech AWM > Protection formulaires; conserver Standard tant que les sites n'ont pas passé les tests terrain.
5. Les formulaires Gravity Forms et Contact Form 7 ne sont pas modifiés par ce lot. Un pare-feu et une protection anti-automatisation côté hébergeur restent recommandés.

En cas de faux positif, le mode Surveillance permet de laisser passer les contacts pendant l'analyse. Le mode Désactivé est réservé à un dépannage temporaire documenté.

## Hub Client AWM 1.14.18 — CRM Client AWM local et chiffré
Ajoute le premier socle **CRM Client AWM** directement dans `/hub/`. Les soumissions de formulaires sont enregistrées dans un miroir local chiffré. Lorsque le module CRM Client AWM est appliqué au client, Hub Client transmet à LeadTracker uniquement l attribution, les champs techniques nécessaires et les empreintes d identité pour la déduplication.

Le CRM Client affiche une première boîte de réception de leads locale dans Hub Client. Pipeline, rendez-vous, opportunités, ventes et connecteurs CRM bidirectionnels sont conservés au roadmap suivant.

## Hub Client AWM 1.14.17 — scanner Elementor exhaustif
Le bouton **Synchroniser les formulaires** peut maintenant retrouver les formulaires Elementor Pro même lorsqu'ils sont dans d'anciennes pages, des templates, des popups ou des containers imbriqués. Le scan n'est plus limité aux 180 documents Elementor les plus récents et remonte un diagnostic précis à CallTracker lorsque aucun widget Form n'est trouvé.

## Hub Client AWM 1.14.16 — Gravity Forms + Elementor + Contact Form 7
L’inventaire de formulaires retourné à Alliance couvre désormais Gravity Forms, Elementor Pro Forms et Contact Form 7. Le scan Elementor choisit le premier identifiant réellement non vide (`form_id`, `form_name`, ID widget), ce qui corrige des formulaires auparavant invisibles.

## Hub Client AWM 1.14.15 — détection à la demande
- Expose l inventaire formulaires dans le canal privé `update/status` déjà authentifié par site.
- Permet à CallTracker d actualiser immédiatement Gravity Forms/Elementor tout en conservant l anti-rafale Core.

## Hub Client AWM 1.14.14 — inventaire formulaires
- Remonte à CallTracker les formulaires Gravity Forms et Elementor détectés sur ce WordPress via la synchronisation inventaire existante.


## Mise à jour 1.14.12 — 2026-10-01
- UX multi-formulaires par campagne et synchronisation Alliance/Hub Client simplifiée.
# Hub Client AWM 1.14.11
Téléchargement de paquets renforcé : repli non streamé automatique lorsqu’un hébergeur produit un fichier temporaire vide malgré HTTP 2xx.

Recovery reste présent, mais n est plus une condition bloquante pendant la phase de déploiement massif. Hub Client conserve la sécurité de paquet, le rollback local et la vérification après installation.

# Hub Client AWM 1.14.9

Recovery 1.2.5 prend en charge les bases MySQL partagees entre plusieurs WordPress lorsque chaque site possede un prefixe de tables distinct. Le Hub certifie uniquement le prefixe du WordPress courant; les tables des autres sites sont hors scope et ne sont jamais modifiees.

### Recovery zero-clic — Hub Client 1.14.8
Core peut demander en une seule operation la reparation Recovery, la validation objective du perimetre, le checkpoint complet et le test de restauration. Le Hub Client ne retourne `recovery_ready_for_auto=1` qu apres les preuves reelles deja exigees par Recovery.

# Hub Client Awm 1.14.5 — Mapping formulaires piloté par campagne

Synchronise automatiquement les mappings Elementor/Gravity Forms définis dans CallTracker tout en conservant les mappings locaux manuels comme secours.

# Hub Client AWM 1.14.4

Hub Client revient a une architecture volontairement simple: une seule extension WordPress classique dans `wp-content/plugins/hub-client-awm`.

## Mise a jour
Core AWM fournit le paquet signe, Hub Client verifie le SHA-256, stage la nouvelle version, conserve le slot precedent pour rollback, promeut le dossier canonique puis Core relit le site dans une nouvelle requete. Le succes exige la version cible, l extension active, `classic_mode=1` et `boot_ok=1`.

Aucun System Agent MU n est requis. Si un ancien agent ou loader AWM existe encore pendant la transition, Core peut l utiliser uniquement comme secours, puis demander son nettoyage apres confirmation du Hub classique.

## Securite
- HMAC et secret de scan par site.
- SHA-256 obligatoire.
- No-downgrade.
- Transaction Deploy Engine v3 et slot de rollback.
- Recovery obligatoire avant les mises a jour automatiques.
- Aucune suppression des donnees, historiques ou sauvegardes AWM pendant l harmonisation.

## Installateur WordPress
Depuis 1.14.3, la protection AWM ne bloque plus l installation d une nouvelle extension (`action=install`). Les mises a jour d extensions deja presentes restent protegees par Tech/Recovery.

## Gravity Forms
Depuis 1.14.4, la réception directe des formulaires prend en charge Gravity Forms en plus d Elementor Pro Forms. Les formulaires Gravity Forms actifs sont détectés automatiquement, l attribution utilise leur ID numérique stable et chaque soumission est transmise serveur-à-serveur à CallTracker avec une source distincte.


### Recovery SQL mutualise
Hub Client 1.14.6 tente d abord une base de test distincte. Si le privilege CREATE DATABASE est absent, il demande automatiquement a Recovery 1.2.4 un test par tables sandbox isolees dans la base WordPress, sans toucher aux tables de production.
## CallTracker multi-sites
Hub Client filtre les mappings centraux selon son `home_url()` exact afin que deux WordPress distincts sur le même domaine ne se partagent pas les mauvais formulaires.

## Design Composer v2 — Hub Client 1.14.36
Le portail applique famille, couleur, typographie, surface, mouvement et densité, tout en gardant Light/Dark autonome et `prefers-reduced-motion` prioritaire.


---

## ROADMAP.md

# Hub Client AWM 1.14.44

Suite AWM 4.5.470 — Identité de l’en-tête client · 22 octobre 2026.

Hub Client 1.14.44 affiche le logo client seul dans le bloc de marque; à défaut, favicon et noms de compagnie/utilisateur; à défaut, logo AWM et ces noms. Les images défaillantes passent au repli suivant. Le rendu garde proportions, accessibilité et largeur mobile, sans changer les préférences d’apparence.

Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.470.md. Les vérifications locales du code et du navigateur ne constituent pas une installation WordPress ni une validation sur le site de production.

## Futur examiné

Trois nouvelles pistes sont différées : provenance du visuel, lisibilité du logo sur les deux fonds et comparaison des icônes à leur taille réelle. Les propositions précédentes restent tracées; aucun nouvel outil de génération ou de retouche de marque n’est livré dans cette correction.

---

# Hub Client AWM 1.14.43

Suite AWM 4.5.469 — Aperçu avant enregistrement · 22 octobre 2026.

Deux démonstrations clair/sombre réagissent immédiatement aux choix du formulaire avec le CSS réel du portail : carte, H1/H2/H3, texte, boutons, champ, badge et indicateur. Neutral propose les détails de cinq rôles, les polices détectées ou en bibliothèque et les poids contrôlés 100..900; les recettes nommées restent complètes. Les modifications restent locales jusqu’à Enregistrer les deux profils; la bascule du haut conserve son comportement.

Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.469.md. Les essais utilisent le code PHP/CSS/JavaScript réel avec services WordPress substitués; ils ne valent pas installation ou validation sur le site de production.

## Futur examiné

Les trois nouvelles pistes de la revue 469 sont différées. Les autres propositions et leur historique restent ci-dessous; la démonstration locale du formulaire Apparence est désormais livrée, sans préjuger d’une prévisualisation de tous les écrans métier.

---

## 1.14.42 — 2026-10-22

Suite AWM 4.5.468 — Bascule clair/sombre et profils distincts.

Le bouton ◐ connecté est de nouveau une vraie bascule : changement immédiat, enregistrement authentifié du mode seul, retour visible en cas d’erreur et formulaire de repli sans JavaScript. Apparence présente Paramètres clairs et Paramètres sombres, chacun avec les six axes du catalogue et cinq couleurs de surface. Les polices Neutral, leurs graisses et la couleur secondaire sont explicitement communes. Les éditions en cours restent intactes pendant une bascule.

Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.468.md. Aucune installation ni publication de cette version sur l’hébergement n’est présumée.

---

## Livraison 1.14.41 — Suite 4.5.466

Le formulaire existant propose Automatique · logo puis site, Toujours sombre et Toujours clair. Son aide explique la mémorisation du choix et sa priorité sur l’analyse automatique. Les contrôles de persistance utilisent le vrai formulaire, le handler du portail et le callback Core, avec transport et stockage de test. Le choix du portail reste indépendant du mode administratif.

## Validation et portée

Cette version fait partie de Suite AWM 4.5.466. Les preuves détaillées sont dans `PREUVES-VALIDATION-SUITE-AWM-4.5.466.json` et le rapport `VALIDATION-SUITE-AWM-4.5.466.md` de la Suite. Elles couvrent le rendu PHP et Chromium, les modes opposés, les bascules, les identités distinctes et la persistance du choix du portail. Les tests s’exécutent localement avec données et services WordPress substitués; ils ne constituent pas une installation sur le site de production.

Les préférences client ne sont pas modifiées par l’ouverture d’une carte ou d’une fiche administrative, ni par une bascule Core. Les anciennes notes ci-dessous restent historiques : pour cette livraison, les cartes et fiches administratives utilisent la variante Core, tandis que Hub Client conserve son choix indépendant.

---

## Revue 1.14.40 — 2026-10-22 · Suite 4.5.464

### Maintenant

Consommer l’apparence du profil client, automatique depuis logo/site ou choisie manuellement, indépendamment du mode administratif Core. Préserver la personnalisation et son retour volontaire à l’automatique, avec le même profil et le même catalogue partagés par Hub et CRM.

Les réglages de densité existants **Compact, Standard et Confortable** sont réellement appliqués au portail et à la fiche CRM. Les anciennes valeurs fixes du `body` du portail et des alias CRM ne masquent plus les tokens partagés : `--hub-gap`, `--hub-panel-pad`, `--hub-control-height` et `--hub-cell-padding`. Espacement, panneaux, hauteur des champs et cellules de tableau suivent le profil choisi. Le catalogue et les autres axes restent inchangés.

La précision finale porte sur les six choix existants : Style, Couleur, Typographie, Surface, Mouvement et Densité. En automatique, Hub rapproche chaque indice exploitable du CSS du site des options du catalogue. Neutral, Auto, Subtle et Standard sont les replis respectifs de typographie, surface, mouvement et densité lorsqu’aucun indice exploitable n’existe, notamment pour un logo seul. Les choix manuels restent prioritaires.

### Futur

L’aperçu en direct et l’historique des personnalisations restent différés. La revue des dix modules ajoute cinq propositions distinctes : verrouillage sélectif des axes lors d’une réanalyse, veille des changements d’identité avant adoption, zone utile du logo, simulation de perception des couleurs et création de styles depuis une URL dans Design System & QA de Core. Ces propositions ne sont pas mises en œuvre par cette livraison.


## Livré 1.14.39 — 2026-10-21
- [x] L écran Apparence consomme le catalogue Design Composer reçu de Core/Hub AWM au lieu de maintenir un catalogue figé.
- [x] Le client voit la source de son thème recommandé et peut personnaliser famille, couleur, typographie, surface, mouvement et densité.
- [x] Le bouton de réinitialisation devient `Revenir au thème automatique · logo -> site -> AWM`.
- [x] Les tokens compilés par Core sont prioritaires pour géométrie, typographie, surfaces, mouvement et rythme du portail.
- [x] Le même profil visuel est appliqué aux vues Accueil, CRM, Stats, LeadTracker/CallTracker, Soutien, Assistant et futurs services compatibles rendus dans le portail.
- [x] `prefers-reduced-motion` reste prioritaire.

## 1.14.38 - Surface & Mouvement v2
- [x] 12 surfaces portail.
- [x] 12 mouvements portail.
- [x] Styles Studio page-scoped alignés.
- [x] reduced-motion prioritaire.
- [ ] Futur : aperçu temps réel du profil client depuis Hub AWM.

## 1.14.37 - Design Composer Studio
- [x] Recevoir et nettoyer profil/tokens Studio.
- [x] Appliquer les tokens à la page sans dépendre du CSS administratif Core.
- [x] Conserver reduced-motion et métadonnées de design pour audit.
- [ ] Workflow explicite pour publier le profil dans Elementor Globals avec preview, sauvegarde et rollback.

## 1.14.35
- Contrat Design dynamique par client.
- Futur : comparaison de themes avant publication et suggestions automatiques de famille a partir de l identite du site.

## Maintenant - 1.14.34
- Identity Mapping v2 aligne avec LeadTracker 1.11.75.
- Confirmer sur le prochain vrai lead que le nom du prospect reste correct dans Capturia.
- Ne pas rejouer les anciens leads et ne pas lancer de formulaire test artificiel.

## 2026-10-18 - Hub Client AWM 1.14.33 - mappings de campagne actifs auto-appliqués

- Hub Client ne dépend plus d’un clic administrateur pour appliquer les mappings d’une campagne active.
- Un worker local actualise les campagnes/mappings Alliance toutes les cinq minutes et remplace automatiquement les associations gérées par Alliance; une campagne mise en pause disparaît donc du routage géré lors de la prochaine synchronisation.
- Chaque vraie soumission Elementor, Gravity Forms, Contact Form 7 ou hook AWM force en plus une lecture fraîche de `forms/campaigns` avant de résoudre la route. Une campagne activée ou modifiée quelques secondes auparavant ne peut plus être masquée par le cache de cinq minutes.
- Les mappings explicites restent prioritaires et VMV-NAT conserve son fallback `capturia_auto_all_forms`.
- Aucune soumission historique n’est rejouée par ce worker; il ne fait que synchroniser la configuration de routage.

# 2026-10-18 - Hub Client AWM 1.14.32 - complément données Capturia sans doublon

- [x] Respecter la propriété centrale `central_owned` renvoyée par LeadTracker.
- [x] Ne jamais recréer un contact déjà créé par LeadTracker.
- [x] En mode confidentialité, ajouter seulement les notes complètes au contact central exact.
- [x] Mettre à jour le même reçu technique grâce au `local_ref`.
- [ ] Validation terrain au prochain vrai lead VMV-NAT.

# 2026-10-16 - Hub Client 1.14.31 - Capturia immédiat sur le lead exact

- [x] Traiter le `local_ref` exact du nouveau formulaire au lieu de la plus ancienne ligne de la file.
- [x] Publier une preuve `pending` PII-free dès que le formulaire central LeadTracker existe.
- [x] Envoyer toutes les notes Capturia dans la même capture normale, sans délai artificiel.
- [x] Conserver les reprises uniquement pour HTTP 429, panne sûre avant mutation ou résultat réseau incertain.
- [x] Conserver l'idempotence et l'interdiction de rejouer aveuglément une réponse incertaine.
- [ ] Valider sur le prochain vrai lead client, sans formulaire test artificiel : la ligne doit afficher `Confirmé · Contact ✓ · Google ✓ · Données ✓` avec ID contact et preuve API.
- [ ] Synchroniser la roadmap publique après validation terrain.

## 2026-10-16 - Hub Client 1.14.30 / Suite AWM 4.5.420 - Capturia déclenché par la réponse autoritaire du lead

- Corrige le défaut terrain persistant où un lead VMV-NAT entrait dans LeadTracker mais restait `Sans preuve` sans jamais atteindre la file Capturia.
- Le flux ne dépend plus d'une seconde lecture de `forms/campaigns` après la capture. LeadTracker retourne avec `forms/submit` une instruction PII-free pour la campagne exacte; Hub Client l'utilise immédiatement.
- Séquence normale : miroir local chiffré → `forms/submit` → instruction Capturia autoritaire → file idempotente locale → création contact → étiquette Google → données → reçu technique LeadTracker, dans le même traitement.
- Si la clé, les scopes, l'étiquette ou le Connector empêchent l'envoi, la ligne locale passe en reprise contrôlée et une preuve technique peut remonter; elle ne doit plus rester silencieusement `Sans preuve`.
- Le cron n'est qu'un secours. Aucun des historiques 563 n'est rejoué et une réponse réseau incertaine n'est jamais renvoyée aveuglément.

## 2026-10-16 - 1.14.29 / Suite AWM 4.5.419 - Capturia immédiat sans relecture de cache au verrou final

- Corrige le défaut terrain de 1.14.28 : `on_form_captured()` lisait bien VMV-NAT en mode frais, mais `enabled()` puis `process_queue()` pouvaient relire aussitôt le cache précédent et interrompre l'envoi.
- Le chemin de capture force désormais le contrat frais de bout en bout (`target(true)`, `enabled(true)`, `process_queue('capture')`) avant toute écriture Capturia.
- Tout nouveau formulaire VMV admissible est mis en file idempotente et traité immédiatement dans la même requête. Le cron reste uniquement une reprise contrôlée sur erreur/rate-limit.
- Les mappings explicites vers une autre campagne restent prioritaires; aucun historique n'est rejoué automatiquement et les réponses réseau incertaines restent non rejouées aveuglément.

## 2026-10-15 - 1.14.26 / Suite AWM 4.5.415 - VMV-NAT Capturia automatique pour tous les formulaires

- Quand la destination Capturia est active sur VMV-NAT, tout formulaire capturé sur le WordPress principal de Vendre Maison Vite est automatiquement attribué à VMV-NAT et mis en file Capturia, sans exiger une sélection manuelle formulaire par formulaire.
- Une association explicite du formulaire à une autre campagne reste prioritaire : VMV-GADS, VMV-FADS, VMV-YT et toute autre campagne ne sont jamais déplacés silencieusement vers VMV-NAT.
- Elementor, Gravity Forms, Contact Form 7 et le hook générique Hub Client suivent le même contrat. Les moteurs futurs qui passent par le hook générique héritent automatiquement du routage.
- Le rattrapage récent 36 h est versionné à nouveau afin de mettre en file les captures VMV-NAT récentes sans livraison locale, sans rejouer les 563 historiques et sans dupliquer une ligne déjà livrée.
- Capturia reçoit toutes les données métier utiles du formulaire; la preuve renvoyée à Alliance reste strictement PII-free.

## 2026-10-15 - 1.14.25 / Suite AWM 4.5.413 - Capturia multi-formulaires et rattrapage recent cible

- Corrige le routeur Capturia VMV-NAT qui etait encore limite a `hub_client_elementor` dans 1.14.24. Les formulaires explicitement mappes Elementor, Gravity Forms et Contact Form 7 suivent maintenant le meme circuit Capturia.
- Chaque capture calcule un `submitted_at_utc` canonique. Gravity Forms `date_created` est interprete comme UTC; les autres sources historiques sont converties depuis le fuseau WordPress vers UTC.
- Le recu de preuve PII-free ajoute source, identifiant de formulaire, phase et curseur de notes afin que LeadTracker affiche les etapes de livraison.
- A la premiere synchronisation 1.14.25, un rattrapage borne aux 36 dernieres heures inspecte le miroir local chiffre, resoumet les formulaires au registre central avec leur identifiant stable, puis met en file Capturia uniquement les lignes qui n ont jamais eu de livraison locale.
- Ce rattrapage est idempotent, ne rejoue jamais le backfill historique des 563 lignes et ne cree pas une deuxieme ligne Capturia lorsqu une livraison locale existe deja.
- Aucun envoi fournisseur n est execute pendant l installation elle-meme; le worker reste asynchrone et respecte les pauses HTTP 429.

## 2026-10-15 - 1.14.24 / Suite AWM 4.5.410 - VMV-NAT : données CRM complètes et identité visible

- Capturia demeure le CRM du client Vendre Maison Vite : le contact reçoit le nom, le courriel et le téléphone structurés, puis **toutes les réponses utiles du formulaire Elementor** sont conservées dans une ou plusieurs notes Capturia.
- Les champs techniques sensibles (mot de passe, jeton, nonce, captcha, clé API, carte/CVV) sont volontairement exclus du transfert CRM.
- Si les réponses dépassent une note, Hub Client les découpe en notes idempotentes et reprend automatiquement après HTTP 429 sans perdre les parties déjà acceptées.
- Le transport `local_mirror_v1` transmet désormais à LeadTracker uniquement l identité opérationnelle minimale (nom, courriel, téléphone) afin que la liste affiche le vrai contact; le reste du formulaire demeure dans le miroir local chiffré et dans Capturia.
- La table de **preuve Capturia** reste strictement sans PII : identifiants techniques, statut, HTTP/request ID et horodatage seulement.
- Aucun envoi n est déclenché par l installation; le routage reste limité au site principal Vendre Maison Vite et à VMV-NAT.

## 2026-10-15 - 1.14.23 / Suite AWM 4.5.409 - Capturia : preuve de livraison des nouveaux formulaires

- Après l enregistrement central du formulaire, le Hub Client rattache l identifiant technique AWM à la file locale Capturia et renvoie à Alliance un reçu **sans PII** après chaque changement d état.
- Le reçu contient uniquement les identifiants techniques, l état, le code HTTP, l identifiant de requête et l horodatage; aucun nom, téléphone, courriel ni contenu de formulaire n est renvoyé pour cette preuve.
- Les nouveaux envois VMV-NAT respectent `Retry-After` / `RateLimit-Reset`, n utilisent plus une limite fixe de quatre essais sur HTTP 429 et ne traitent qu une ligne Capturia par passage afin de réduire les nouvelles limites API.
- Le prochain passage est replanifié automatiquement lorsqu une ligne reste à envoyer. Les clés d idempotence existantes sont conservées.
- AWM n appelle aucune fonction SMS/courriel Capturia. Les automatisations éventuellement configurées dans le compte Capturia restent hors du contrôle d AWM.
- Aucun formulaire n est envoyé à l installation; la route reste strictement limitée au site principal Vendre Maison Vite et à VMV-NAT.

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

Registre local CRM multicanal avec transactions, charges nominatives chiffrees par Core, index tenant-scopes, endpoints prives et vue du portail CRM.

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.

---

## Phase pilote — 1.14.21 / relais formulaires VMV-NAT vers Capturia
Réutilisation automatique de la clé chiffrée centrale, envoi idempotent vers contact + Google + note, journal local des états; sans SMS ni transfert automatique historique. Vérifier Capturia live, consentement du formulaire, arrêt si campagne/connexion désactivée, et voie de redémarrage après réponse ambiguë.

# Hub Client 1.14.20 — Correctif UTF-8 Studio / Elementor
- [x] Supprimer l'unslash double sur le JSON Elementor, y compris snapshots et relevés.
- [x] Détecter la corruption Unicode historique, empêcher la réécriture et la restauration d'un snapshot déjà corrompu.
- [x] Vérifier l'intégrité des widgets non ciblés, la lecture après sauvegarde et le retour arrière automatique en cas d'écart.
- [ ] Valider avec Elementor réel sur la page pilote de couture-electro.com après restauration d'une révision saine.
- [ ] Vérifier le rendu réel et l'intégralité des contenus historiques de la page endommagée.

# Hub Client AWM 1.14.19 — Protection des soumissions Elementor
- [x] Bloquer au hook validation **avant les courriels clients** et autres actions Elementor.
- [x] Ne pas remonter les formulaires rejetés vers LeadTracker ni le miroir CRM Client.
- [x] Détection locale graduée + preuves HMAC et piège invisible + limitation des répétitions.
- [x] Métriques et journal local sans coordonnées nominatives; coût sans API distante par lead.
- [x] Pilotage privé de l'état par le canal Tech AWM / site_id / instance_uuid.
- [x] Modes Surveillance, Standard, Strict et Désactivé.
- [ ] Test terrain formulaire Elementor Pro réel avec Email/Email2, webhook, Elementor Submissions et LeadTracker.
- [ ] Vérifier les formulaires dans popups, cache LiteSpeed et pages AMP / variantes de CDN.
- [ ] Ajouter ultérieurement des règles dédiées Gravity Forms et Contact Form 7 avec leurs hooks de pré-envoi respectifs.
- [ ] Statistiques temporelles 24 h / 7 jours et assistant de revue des faux positifs dans Tech AWM.

# Hub Client AWM 1.14.18 — CRM Client AWM
- [x] Miroir local chiffré des leads formulaires.
- [x] Module CRM Client AWM activable depuis les services du client.
- [x] Vue CRM locale dans `/hub/` sans wp-admin.
- [x] Enveloppe de confidentialité vers LeadTracker lorsque le CRM Client est actif.
- [x] Conserver la donnée locale si le centre est temporairement indisponible.
- [ ] Pipeline Kanban configurable.
- [ ] Contacts, opportunités, rendez-vous, ventes et revenus.
- [ ] Connecteurs CRM/API génériques avec mapping et synchronisation bidirectionnelle.
- [ ] Consentement explicite et journalisé pour tout partage identifiable au-delà du site client.

# Hub Client AWM 1.14.17 — Elementor exhaustif
- [x] Lever la limite des 180 derniers documents Elementor.
- [x] Rechercher les documents contenant réellement un widget Form avant parsing.
- [x] Repli via API Documents Elementor + `_elementor_data`.
- [x] Diagnostic de scan remonté à CallTracker.

## Hub Client AWM 1.14.16 — livré / validation terrain
- [x] Détection Contact Form 7.
- [x] Capture serveur-à-serveur des envois Contact Form 7.
- [x] Détection Elementor renforcée quand `form_id` est vide.
- [x] Inventaire immédiat utilisable par le bouton CallTracker « Synchroniser les formulaires ».

## Hub Client AWM 1.14.15 — livré / validation terrain
- [x] Retourner `form_inventory` dans `update/status`.
- [x] Conserver la détection locale Gravity Forms + Elementor Pro Forms.
- [x] Conserver le `home_url()` exact, chemin inclus.
- [ ] Valider la remontée immédiate depuis CallTracker sur les deux WordPress Soltech.

## Hub Client AWM 1.14.14 — inventaire formulaires
- Remonte à CallTracker les formulaires Gravity Forms et Elementor détectés sur ce WordPress via la synchronisation inventaire existante.


## Mise à jour 1.14.12 — 2026-10-01
- UX multi-formulaires par campagne et synchronisation Alliance/Hub Client simplifiée.
## Livré 1.14.11
- Double chemin de téléchargement paquet : streaming puis repli non streamé.
- Conserver Recovery au roadmap futur comme certification asynchrone non bloquante.

## Livré 1.14.10
- Mode flotte : Recovery différé, mises à jour Hub/Tech/modules non bloquées.
- Switch de réactivation conservé pour une future phase de certification Recovery.

## Futur
- Réactiver Recovery après stabilisation des 80+ sites, comme job asynchrone non bloquant.

## Livre 1.14.9
- [x] Certification Recovery automatique sur base partagee avec isolation stricte par prefixe WordPress.
- [x] Scope Recovery valide sur les tables du site plutot que sur toute la base MySQL.

## 1.14.8 — Recovery zero-clic
- [x] Accepter la preparation automatique auditee demandee par Core.
- [x] Conserver les controles objectifs base dediee + layout/Vault avant validation du scope.
- [x] Conserver le vrai test fichiers + SQL et le nettoyage sandbox obligatoires.
- [ ] Valider sur plusieurs topologies d hebergement avec l Autopilote actif.

# Mapping formulaires piloté par campagne — 1.14.5

**Livré :** Synchronise automatiquement les mappings Elementor/Gravity Forms définis dans CallTracker tout en conservant les mappings locaux manuels comme secours.

**Validation terrain :** confirmer le parcours sur un site pilote avant généralisation à toute la flotte.

# Hub Client AWM 1.14.4 - Gravity Forms + runtime classique unique
- [x] Hub Client normal = `wp-content/plugins/hub-client-awm`.
- [x] Gravity Forms natif: détection des formulaires, attribution par campagne et capture serveur-à-serveur.
- [x] Elementor Pro Forms reste compatible sans changement.
- [x] Installation de nouvelles extensions WordPress autorisee; seules les mises a jour/remplacements existants restent sous protection AWM.
- [x] Plus d auto-migration ni d auto-seed MU depuis Hub Client.
- [x] Preuve de sante simple: version + actif + `classic_mode` + `boot_ok`.
- [x] Commit v3 compatible avec une mise a jour Hub -> Hub sans MU permanent.
- [x] Nettoyage cible des anciens loader/runtime/config AWM MU apres confirmation du runtime classique.
- [x] Recovery reste obligatoire pour l Autopilote; le deploiement manuel conserve backup/rollback local.
- [ ] Valider la flotte complete puis retirer le code historique MU devenu inutile dans une version ulterieure.

- [x] Recovery 1.2.4 : fallback SQL sandbox dans la base courante pour les hebergements sans CREATE DATABASE.

## Livré 1.14.13
- Filtrage des mappings de formulaires par site WordPress exact, chemin inclus.

## 2026-10-21 — Design Composer v2
- Livré : typographie, surface et mouvement.
- Futur : iconographie contrôlée, prévisualisation multi-thèmes et score local de lisibilité.