README

# 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.