Contexte développement

# Contexte développement — Core AWM 4.5.328


---

## CHANGELOG.md

# Core AWM 4.5.328

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

Core 4.5.328 consigne le contrat d’identité de l’en-tête et ajoute favicon_url au payload utilisateur authentifié, depuis le favicon choisi ou détecté dans l’identité canonique du client. La mémoire reçoit une décision, avec 144 entrées antérieures conservées. Permissions, sessions, coffre, catalogue et compilateur restent sous leurs contrats existants.

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.

---

# Core AWM 4.5.327

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

Publie les recettes de prévisualisation canoniques et ajoute dans Design System & QA le parcours URL → brouillon → aperçu clair/sombre → approbation explicite → application comme défaut client. Les actions utilisent les permissions Core/CRM et des nonces; aucun modèle n’est approuvé automatiquement. Le registre conserve des configurations contrôlées et leur empreinte; la bibliothèque réutilise ou télécharge les fichiers de police manquants, avec variantes et origine. La mémoire ajoute deux décisions en conservant les 142 règles précédentes.

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.

---

## 4.5.326 — 2026-10-22

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

Le contrat d’apparence valide les deux profils avant toute écriture. Une bascule seule enregistre uniquement le choix Auto/clair/sombre et préserve les profils et l’identité automatique. Le raccordement administratif applique les variables et les classes du profil correspondant au mode Core. La mémoire consigne la décision et conserve les 141 entrées antérieures.

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.

---

## 4.5.325 — 2026-10-22 · Suite AWM 4.5.467

L’utilisateur a accepté la Suite **4.5.466** comme référence d’apparence puis demandé l’inscription de cette décision dans la mémoire Core, les journaux et les roadmaps. La décision `AWM-APPEARANCE-BASELINE-466-001` est ajoutée au seed `2026-10-22.4`; les 139 entrées antérieures restent identiques.

Les cartes et fiches administratives CRM et Hub conservent les couleurs et les six axes du client, avec la variante claire/sombre du Core de l’opérateur. Hub Client conserve indépendamment **Automatique · logo puis site**, **Toujours sombre** ou **Toujours clair**. La personnalisation manuelle reste prioritaire sur la réanalyse; l’affichage administratif n’écrit aucun choix client.

Le lot officiel de migration mémoire de 4.5.466 garde son identifiant immuable `2026-10-22.3`, distinct de la version du seed courant. Un site qui passe directement de 4.5.465 à cette version peut donc encore appliquer ses révisions officielles bornées, avec les mêmes empreintes autorisées et protections des révisions humaines. La nouvelle décision est insérée par le mécanisme de mémoire existant et ses événements de journalisation habituels.

La création de styles depuis une URL dans **Core → Design System & QA** reste proposée et différée. L’acceptation de la livraison ne constitue ni une installation sur l’hébergement ni une validation en production. Les résultats locaux de cette Suite sont documentés dans son rapport de validation.

## Accès au Hub Client depuis la fiche CRM

La décision `AWM-CRM-HUB-SITE-USERS-001` précise le bloc permanent **Hub Client & connexion** rendu par Hub 4.5.110 dans la fiche CRM. Quand le site principal est lié par un Connector runtime autorisé, ses comptes WordPress apparaissent avec leurs cases de sélection. Le scan et l’enregistrement utilisent l’annuaire et l’allowlist existants de Core, avec leurs permissions, le nonce CRM et le périmètre explicite du site principal. Un simple affichage ou scan n’accorde aucun accès. Les références invalides et les sélections fondées sur un annuaire périmé sont refusées. Les cases utilisent les références stables Core; une modification réelle des droits réutilise la révocation des sessions API du site concerné et les journaux Core existants.

Le raccourci **Hub Client** ouvre le portail du site appairé dans un nouvel onglet, en conservant le sous-dossier WordPress et l’authentification ou la session existante. Il ne crée pas de nouveau SSO. Les deux nouvelles décisions portent la mémoire à **141 clés uniques**, sans modifier les 139 entrées de 4.5.466. Core reste l’autorité des droits et du transport; cette interface est fournie par Hub.

---

## 4.5.324 — 2026-10-22

Core choisit la variante claire ou sombre des cartes et fiches administratives explicitement marquées, en conservant leurs couleurs et leurs six axes client. La synchronisation se fait dès le rendu et lors des bascules, sans écriture de préférence client. Les règles du shell respectent ces zones personnalisées. Les règles officielles de mémoire concernées évoluent par révisions bornées et vérifiées; les révisions humaines sont préservées.

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

---

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

- Consigne l’idée utilisateur de création de styles depuis une URL dans Design System & QA comme évolution proposée et différée; aucun runtime de génération ajouté.
- Consigne dans les contrats la demande de rapprocher automatiquement les six axes des choix existants : les indices CSS déterminent aussi typographie, surface, mouvement et densité; Neutral/Auto/Subtle/Standard sont les replis sans indice et les profils manuels restent prioritaires.
- Corrige explicitement notre décision 4.5.463 : le contenu CRM adopte le profil personnalisé Hub Client demandé par l’utilisateur; le header, les guides et la navigation du shell restent Core.
- Rend publique `CallLink_Client_API::style_payload(WP_User)` sans modifier son corps canonique ni créer de route.
- Ajoute `.callink-crm-client-themed` et ses descendants aux exclusions des sélecteurs administratifs déjà gardés; la fiche Hub conserve sa frontière existante.
- Préserve `data-client-color-scheme` lors des synchronisations du mode administratif; le shell ne remplace pas l’apparence propre au client.
- Révise les règles de mémoire concernées dans leurs clés existantes, l’architecture et la revue des dix modules en `2026-10-22.1` — 139 règles uniques.
- Consigne la précision utilisateur sur le choix d’une combinaison disponible, par exemple Arctic + Rouge, sans reconstruction du CSS du site.
- Diffère les cinq nouvelles pistes Futur; les preuves locales de cette livraison sont documentées séparément.

Les assertions visuelles CRM = Core des entrées 4.5.322 / Suite 4.5.463 ci-dessous sont historiques et remplacées par la décision 4.5.323.

## 4.5.322 — 2026-10-21

- Actualise mémoire, architecture et revue Futur en `2026-10-21.16`, pour Suite 4.5.463 et Core 4.5.322.
- Ajoute `AWM-CRM-ADMIN-DESIGN-COMPOSER-001` : le dossier CRM consomme le profil administratif Core complet et charge réellement la feuille CSS métier de sa route.
- Précise que les exceptions de profil client concernent les cartes Hub et `.callink-client-detail-themed`, sans les étendre aux fiches CRM contenant un `client_id`.
- Conserve le contrat de parité carte/fiche Hub; Hub AWM 4.5.107 et Hub Client 1.14.39 sont reconduits.
- Porte la mémoire à 139 clés uniques. Le mécanisme documentaire Core actualise les révisions, sans migration des données métier.
- Consigne la roadmap publique V4.5.462 observée directement le 21 octobre à 16:50:12 HAE. Cette observation ne constitue pas une publication 4.5.463 ni une preuve du rendu CSS.
- Réexamine les dix modules et documente quatre nouvelles capacités différées, dont une palette de commandes contextuelles pour Core.

## 4.5.321 — 2026-10-21

- Complète la frontière CSS de 4.5.461 avec un contrat explicite de profil complet identique entre la carte client et sa fiche.
- Corrige `module_from_request()` : le classement exact de `awm-hub-clients` comme route centrale précède l’exclusion du véritable portail Hub Client. Le contexte Core et les styles du shell/guides sont ainsi disponibles sur la fiche, au lieu de dépendre du secours limité à la liste.
- Conserve l’autorité du thème principal sur le shell et sa navigation sans imposer ce profil aux contenus client.
- Ajoute `AWM-HUB-CLIENT-PROFILE-PARITY-001` et précise les règles de carte et de frontière CSS : l’isolation ne remplace pas la compilation des six axes du Design Composer.
- Actualise mémoire, architecture et revue Futur en `2026-10-21.15`, avec Suite cible 4.5.462 et Core 4.5.321.
- Consigne la roadmap publique 4.5.461 observée directement le 21 octobre à 15:38:29 HAE. La validation et la publication de 4.5.462 restent distinctes de cette preuve.

## 4.5.320 — 2026-10-21

- Corrige le débordement CSS signalé dans la fiche client / Identité visuelle après la Suite 4.5.460.
- Exclut `.callink-client-detail-themed` et tous ses descendants des sélecteurs visuels Core avec un filtre de spécificité nulle; retire les neutralisations historiques des tokens `--client-*`.
- Conserve le bootstrap et les marqueurs Light/Dark du shell, son header, les guides administratifs et les cartes personnalisées de la liste.
- Ajoute `AWM-CLIENT-THEME-CSS-BOUNDARY-001` et clarifie les règles historiques Design System/presets pour respecter les familles dynamiques et les scopes client autorisés.
- Actualise mémoire/architecture/revue Futur en `2026-10-21.14`; référence Suite 4.5.461 et Core cible 4.5.320. La mémoire documentaire peut se mettre à niveau normalement, sans migration des données métier.
- Consigne la consultation publique directe du 21 octobre à 15:14 HAE : roadmap affichant 4.5.460. La publication et la validation terrain 4.5.461 restent à confirmer.

# 4.5.318 — 2026-10-21
- Correctif terrain : Hub AWM > Clients restait noir/générique avec Core 4.5.317 alors que le profil principal était `Arctic Cyan · Glow`.
- La route clients reçoit désormais le shell Core même si le header partagé n est pas rendu; fallback JS inclus.
- Le shell de liste reprend fond, surfaces, accent, typographie, densité, rayon, Glow et états interactifs du Design Composer principal.
- Les cartes client restent des scopes isolés.

## 4.5.317 — 2026-10-21

- Corrige la parité du Design Composer : la teinte choisie devient l accent canonique même pour les anciens sélecteurs encore branchés sur `--awm-blue-*`, `--ci-orange`, `--crm-accent`, `--ct-accent` et `--callink-accent`.
- Le moteur JS calcule des variantes claire/pâle/foncée de l accent choisi et les publie comme palette de compatibilité sans modifier les surfaces de famille.
- Sur `Hub AWM > Clients`, les cartes client sont explicitement exclues de la neutralisation administrative et conservent rayon, couleurs, typographie, surface et mouvement propres au client.
- Nouvelle règle Mémoire `AWM-DESIGN-COMPOSER-ACCENT-AUTHORITY-001`; Architecture/Revue Futur `2026-10-21.11`.
- Aucun changement métier ou intégration.

## 4.5.316 — 2026-10-21

- Corrige le retour terrain de Suite 4.5.456 : `Hub AWM > Clients` pouvait afficher un shell clair malgré un Design Composer principal Dark.
- Renforce l autorité Core sur le fond racine, les surfaces, contrôles et état actif de la liste Clients.
- Les cartes clients restent explicitement exclues de cette neutralisation et conservent leurs tokens `--card-*`.
- Ajoute la règle Mémoire `AWM-HUB-CLIENTS-SHELL-THEME-AUTHORITY-001`; mémoire/Architecture/Revue Futur passent à `2026-10-21.10`.
- Aucun changement métier.

## 4.5.315 — 2026-10-21

- Publie le catalogue Design Composer comme contrat partageable pour Hub AWM et Hub Client.
- Le payload Hub Client expose catalogue, tokens compilés, source et libellé de source du thème.
- Le retour au thème automatique relance réellement la détection `logo -> site Web -> thème AWM`.
- Hub AWM > Clients conserve le shell administratif central tandis que les cartes clients peuvent prévisualiser leur profil propre.
- Ajoute les règles de mémoire sur auto-identité, propagation du catalogue, scope de thème des services client et cartes de prévisualisation.

## 4.5.314 - Dialogue du loader harmonise au theme (2026-10-21)
- La carte centrale du loader/fallback n utilise plus un fond bleu fixe.
- Surface, texte, bordure, rayon et ombre suivent les tokens actifs du Design Composer avec fallback sûr.
- Le backdrop subtil 4.5.313 est conserve tel quel : 8 % Light / 12 % Dark, blur 3 px.
- Ajoute la regle Memoire `AWM-ADMIN-LOADER-THEME-CARD-001`; 128 regles; Architecture/Revue Futur `2026-10-21.8`.

## 4.5.313 - Backdrop theme subtil, reference historique (2026-10-21)
- Reduit la teinte du backdrop a 8 % en Light et 12 % en Dark.
- Restaure le blur historique a 3px et supprime la saturation ajoutee en 4.5.312.
- La carte du dialogue retrouve une bordure neutre; seule la toile de fond garde une indication de la couleur active.
- Ajoute la regle Memoire `AWM-ADMIN-LOADER-SUBTLE-BACKDROP-001`; 127 regles; Architecture/Revue Futur `2026-10-21.7`.
- Aucun changement metier.

## 4.5.312 - Roadmap source coverage + overlay accentue (2026-10-21)
- Le preflight Suite exige maintenant qu un module source modifie possede un `roadmap_sync.module_updates` dont la version correspond exactement au ZIP source.
- Le loader Core de secours teinte maintenant le fond floute avec la couleur active du Design Composer au lieu d un voile noir neutre.
- Nouvelle garde : une roadmap stale ne peut plus satisfaire un module simplement parce qu une ancienne entree existe sous le meme slug.

## 4.5.311 - Surface & Mouvement v2 (2026-10-21)
- Corrige l impression que Surface et Mouvement ne changent rien : les règles sont maintenant plus fortes, plus larges et visibles immédiatement dans le laboratoire.
- Passe Surface de 5 à 12 personnalités : Auto, Flat, Outline, Soft tint, Elevated, Floating, Inset, Layered, Glass, Frosted, Gradient et Glow.
- Passe Mouvement de 3 à 12 personnalités : Aucun, Instantané, Discret, Rapide, Doux, Fluide, Élévation, Zoom, Glissement, Ressort, Halo et Cinématique.
- Ajoute un aperçu Surface/Mouvement dédié avec bouton de test du mouvement.
- Le mouvement respecte toujours `prefers-reduced-motion` et aucune animation permanente n est imposée.

## 4.5.310 - Pont Design Composer vers Studio Web (2026-10-21)
- Ajoute un compilateur de tokens Web neutres à partir des profils Design Composer Core.
- Expose géométrie, couleur, typographie, surface, mouvement et layout sans écrire directement dans WordPress ou Elementor.
- Studio peut désormais réutiliser le même langage visuel pour construire des pages de site tout en gardant la composition et les effets dans Studio.
- Le kit global Elementor existant n est jamais muté automatiquement; une publication globale future devra être explicite, prévisualisée, sauvegardée et réversible.
- Mémoire/Architecture/Revue Futur passent à 2026-10-21.4; 123 règles.

## 4.5.309 - Design Composer v2 : typographie, surfaces et mouvement (2026-10-21)
- Ajoute 5 familles typographiques : Neutral, Humanist, Technical, Compact et Executive.
- Ajoute les surfaces Auto, Flat, Bordered, Elevated et Translucent comme axe indépendant de la géométrie.
- Ajoute le mouvement Aucun, Discret ou Fluide avec `prefers-reduced-motion` prioritaire.
- Le contrat devient Famille × Couleur × Typographie × Surface × Mouvement × Light/Dark × Densité.
- Les piles de polices Core restent locales/système; aucune police distante n est nécessaire.
- Hub AWM et Hub Client peuvent recevoir les mêmes axes sans CSS arbitraire.
- Mémoire/Architecture/Revue Futur passent à 2026-10-21.3; 122 règles.

## 4.5.308 - Compositeur dynamique Style x Couleur x Mode x Densite (2026-10-21)
- Les 5 presets bleus deviennent des familles visuelles independantes de la couleur; migration legacy conservee.
- Ajoute 10 familles : Square, Arctic, Graphite, Electric, Console, Rounded, Soft, Outline, Minimal et Glass.
- Ajoute 9 couleurs predefinies + couleur libre via selecteur natif, ainsi que 3 densites : Compact, Standard, Confortable.
- Light/Dark reste un axe independant. Exemple : Electric Orange Dark Compact.
- Ajoute un contraste automatique de l encre des actions primaires pour les accents clairs comme Jaune/Lime.
- Hub AWM et Hub Client consomment le meme contrat de profil design; Hub peut deriver automatiquement la couleur depuis le logo/site du client.
- Memoire/Architecture/Revue Futur passent a 2026-10-21.2; 121 regles.

## 4.5.307 - Table de référence Dark sans fond clair (2026-10-21)
- Corrige le défaut terrain encore visible dans `Core > Outils avancés > Design System & QA` : la ligne `Exemple Client` de la table de référence restait blanche au repos en mode Dark.
- Cause : la classe WordPress native `widefat striped` applique un fond clair aux lignes impaires; 4.5.303 avait fermé le hover, mais pas l'état de repos.
- Ajoute la classe explicite `awm-design-reference-table` et verrouille `table / tr / th / td` sur les tokens Core pour repos, alternance, hover, focus et sélection.
- Le correctif fonctionne pour tous les presets visuels, en Light et en Dark, sans toucher aux données métier.
- Ajoute la règle Mémoire `AWM-ADMIN-DARK-TABLE-BASE-001`; seed/Architecture/Revue Futur `2026-10-21.1`; 119 règles.
- Hub Client reste exclu; aucun changement Capturia, Twilio, CRM externe, CPL, campagne, lead ou formulaire.

## 4.5.306 - Cohérence de version Core header/runtime (2026-10-20)
- Corrige la divergence terrain exposée par l importeur : le ZIP Core 4.5.305 déclarait encore `Version: 4.5.303` dans son header WordPress alors que `AWM_CORE_VERSION` valait 4.5.305.
- Le header WordPress et `AWM_CORE_VERSION` passent ensemble à 4.5.306.
- `inspect_module_zip()` contrôle désormais explicitement, pour Core, que ces deux valeurs sont identiques avant toute comparaison avec le manifeste Suite et `roadmap_sync.versions`.
- Ajoute la règle Mémoire critique `AWM-CORE-PLUGIN-HEADER-VERSION-001`; seed/Architecture/Revue Futur `2026-10-20.12`; 118 règles.
- Aucun changement métier, CSS, Capturia, Twilio, CPL, campagne, lead ou CRM.

## 4.5.305 - Visual QA : ouverture réellement forcée en nouvel onglet (2026-10-20)
- Retour terrain après 4.5.444 : `target=_blank` était présent dans le HTML mais le comportement attendu n était toujours pas obtenu.
- Les cartes de `Design System & QA > Matrice des pages à vérifier` conservent le fallback HTML `target=_blank` et ajoutent maintenant un clic forcé `window.open(..., _blank)` en capture.
- Toute la carte reste cliquable, avec indication visible `Nouvel onglet` et icône externe.
- Le laboratoire QA ne doit plus être remplacé lors de l ouverture d une route de contrôle.
- Nouvelle règle Mémoire `AWM-ADMIN-VISUAL-QA-FORCED-NEW-TAB-001`; seed/Architecture/Revue Futur `2026-10-20.11`; 117 règles.
- Aucun changement métier; Hub Client reste exclu.

## 4.5.304 - Visual QA en nouveaux onglets (2026-10-20)
- Les liens de la matrice `Design System & QA > Matrice des pages a verifier` ouvrent maintenant chaque ecran dans un nouvel onglet/fenetre.
- La page QA reste donc ouverte pendant la verification de Hub, CRM, LeadTracker, Stats, Assistant, Soutien, Studio et Tech.
- Ajoute `target=_blank`, `rel=noopener noreferrer`, un titre explicite et une indication screen-reader.
- L icone de sortie remplace la simple fleche pour rendre le comportement visible.
- Aucun changement metier ni visuel de theme; Hub Client reste exclu.
- Memoire/Architecture/Revue Futur passent a `2026-10-20.10`; la Memoire contient 116 regles.

## 4.5.303 - Hover Dark lisible et cohérent (2026-10-20)
- Corrige le hover blanc observé en mode Dark dans `Core > Outils avancés > Design System & QA` sur la table d aperçu.
- Étend la correction aux tables administratives centrales WordPress/AWM : le `tr` et ses cellules utilisent désormais le fond hover du preset actif, avec textes principal et secondaire à contraste contrôlé.
- Le correctif couvre les alias Dark Core/legacy afin d éviter un retour aux couleurs natives WordPress pendant une transition de thème.
- Ajoute la règle Mémoire `AWM-ADMIN-DARK-HOVER-CONTRAST-001`; 115 règles; seed/Architecture/Revue Futur `2026-10-20.9`.
- Aucun changement métier; Hub Client reste exclu.


## 4.5.302 - Sélecteur de style explicite + fermeture CSS terrain (2026-10-20)
- Ajoute un vrai sélecteur déroulant de style dans `Core > Outils avancés > Design System & QA`, en plus des cartes d aperçu; le même sélecteur est aussi visible dans `Affichage`.
- Le choix reste instantané, synchronisé et mémorisé par utilisateur, indépendant de Light/Dark et Guidé/Standard/Avancé.
- Corrige les derniers arrondis visibles dans la vidéo terrain : boutons, Light/Dark, champs, listes déroulantes et actions de tableau étaient encore gagnés par des sélecteurs legacy plus spécifiques avec `!important`.
- Ajoute un override final haute priorité sous `#wpbody-content` : toutes les surfaces AWM centrales deviennent strictement carrées; seuls les vrais points de statut et radios restent circulaires.
- Ajoute à Design System & QA une section `Suggestions & prochaines étapes` : diff visuel, lint CSS, grille d espacement, états unifiés, responsive, WCAG, tableaux communs et captures de référence.
- Règle Mémoire `AWM-ADMIN-VISUAL-SELECTOR-QA-001`; 114 règles; seed/Architecture/Revue Futur `2026-10-20.8`.
- Hub Client reste exclu; aucun changement Capturia, Twilio, CPL, campagne, lead, formulaire ou CRM externe.


## 4.5.301 - Contrat de version source renforcé (2026-10-20)
- Corrige le parcours d import Suite après le refus terrain de 4.5.440 sur la garde de cohérence de version Core.
- Normalise explicitement les trois valeurs comparées (`ZIP`, `manifest.modules.*.version`, `roadmap_sync.versions.*`) avant la comparaison stricte.
- En cas de divergence, le message affiche désormais les trois versions réellement observées afin de rendre le diagnostic immédiat.
- Ajoute la règle Mémoire `AWM-SUITE-SOURCE-VERSION-TRIPLET-001` : chaque build doit valider le triplet exact de version pour les dix modules avec la même logique que l importeur Core avant livraison.
- Core passe à 4.5.301; aucune modification des presets visuels 4.5.300, de Square Blue, des données métier ou des connecteurs.
- Mémoire/Architecture/Revue Futur passent à `2026-10-20.7` avec 113 règles.

## 4.5.300 - Design System & QA + styles visuels multiples (2026-10-20)
- Ajoute cinq presets administratifs changeables en direct et mémorisés par utilisateur : Square Blue, Arctic Blue, Graphite Blue, Electric Blue et Navy Console.
- Light/Dark reste indépendant du preset; les modes Guidé/Standard/Avancé restent indépendants eux aussi.
- Ajoute Core > Outils avancés > Design System & QA avec laboratoire de styles, bibliothèque de composants, matrice de routes critiques et garde visuelle.
- Tous les presets conservent la géométrie sans arrondis résiduels et Hub Client reste exclu.
- Corrige aussi le numéro de version du header WordPress Core pour l aligner sur `AWM_CORE_VERSION`.
- Mémoire ajoute `AWM-ADMIN-VISUAL-PRESETS-001`; seed/Architecture/Revue Futur `2026-10-20.6`.
- Aucun changement Capturia, Twilio, CRM externe, CPL, campagne, lead ou formulaire.


## 4.5.299 - Sweep final sans arrondis (2026-10-20)
- Suite au retour terrain sur LeadTracker > Tableau de cablage des leads, retire le reliquat d arrondis encore visible sur certaines cartes, filtres, chips, champs de recherche, onglets, popovers et boutons.
- Le Design System Core force maintenant un rayon nul sur les surfaces administratives AWM centrales en Light et Dark; seuls les vrais points de statut et les radios gardent une forme circulaire quand elle porte l information.
- Renforce aussi la couverture des composants legacy et des cartes de parcours/cablage qui utilisaient encore des rayons definis localement.
- Hub Client reste explicitement exclu. Aucun changement metier Capturia, Twilio, campagnes, leads, CRM ou CPL.
- Memoire/Architecture/Revue Futur passent a `2026-10-20.5`; le nombre de regles reste 111.

## 4.5.298 - Couverture complete Square Blue + parite Light/Dark (2026-10-20)
- Audit statique de toutes les routes, pages, sous-pages et onglets administratifs AWM centraux a partir des ZIP de Suite 4.5.437.
- Renforce `awm-admin-design-system.css` pour neutraliser les surfaces legacy qui produisaient un melange Light/Dark, notamment Hub > Clients : filtres, actions groupees, cartes, tableaux, titres, dialogues et basculeur de theme.
- Unifie les surfaces recurrentes CRM, LeadTracker, Stats, Assistant, Soutien, Studio et Tech avec les tokens Core sans toucher aux cartes geographiques, graphiques, maquettes Studio ni apercus de sites.
- Le theme est maintenant canonique dans Core et synchronise `awm-admin-dark/light`, `awm-theme-dark/light`, `callink-global-dark` et `callink-dark`; le bouton legacy Hub Light/Dark est intercepte pour ne plus creer un theme local divergent.
- Ajoute la couverture des routes pont `awm-leadtracker-crm`, `awm-stats-crm`, `awm-crm-clients`, `awm-crm-opportunities`, `callink-campaign-linker` et `callink-validation-health`.
- Les ecrans natifs WordPress des campagnes/appels LeadTracker recoivent aussi les tokens Light/Dark Core.
- Hub Client reste explicitement exclu du Design System administratif central.
- Memoire/Architecture/Revue Futur passent au seed/version `2026-10-20.4`; le nombre de regles reste 111.
- Aucun changement Capturia, Twilio, CRM externe, CPL, campagne, lead, formulaire ou donnees metier.

## 4.5.297 - Design System Square Blue centralise (2026-10-20)
- Ajoute le Design System administratif canonique dans Core : palette bleue, geometrie carree, rayons 2-4 px, sans gradients decoratifs ni ombres lourdes.
- Le CSS central est charge en dernier sur les ecrans AWM centraux et harmonise Core, Hub, CRM, LeadTracker, Stats, Assistant, Soutien, Studio et Tech.
- Hub Client est explicitement exclu : son portail et son administration locale conservent leur style autonome.
- Les CSS locaux des modules restent autorises pour la mise en page, les graphiques et les composants metier, mais Core devient l autorite des couleurs, typographies, boutons, cartes, tableaux, formulaires et navigations.
- Les fiches clients du Hub central cessent d utiliser la couleur/typographie du client comme theme complet de l administration; logo et identite restent visibles.
- Ajoute la regle Memoire `AWM-ADMIN-DESIGN-SYSTEM-001`; seed `2026-10-20.3`, 111 regles.
- Architecture et Revue Futur passent a `2026-10-20.3`.

## 4.5.296 - Registre CRM externes optionnels (2026-10-20)
- Ajoute `AWM_Core_External_CRM`, registre générique des fournisseurs CRM externes par client.
- Les secrets/API restent dans le coffre Core; le registre ne stocke que l activation du fournisseur.
- Capturia est le premier fournisseur déclaré et reste, pour l instant, réservé à Vendre Maison Vite.
- L état historique Capturia existant peut être adopté sans migration destructive; une désactivation explicite du client empêche le fallback legacy de se réactiver silencieusement.
- Ajoute la règle Mémoire `AWM-EXTERNAL-CRM-OPTIONAL-001`; seed `2026-10-20.2`, 110 règles.
- Architecture et Revue Futur passent à `2026-10-20.2`.

## 4.5.295 - Capturia Identity Mapping v2 (2026-10-20)
- Memoire Core passe a **109 regles** avec `AWM-CAPTURIA-IDENTITY-MAPPING-001`.
- Le contrat interdit qu un courriel, telephone ou URL devienne un prenom/nom Capturia.
- Le moteur d envoi Capturia n est pas deplace dans Core; LeadTracker reste proprietaire de la creation temps reel et Hub Client du miroir local/confidentialite.
- Architecture/Revue Futur passent a `2026-10-20.1` pour Suite 4.5.434.

## 2026-10-19 - Core AWM 4.5.294 / Suite AWM 4.5.433 - Affichage Guidé / Standard / Avancé

- Ajoute un sélecteur **Affichage** commun à toutes les interfaces AWM : Guidé, Standard et Avancé.
- Le choix est mémorisé par utilisateur WordPress et peut être changé instantanément depuis l entête AWM sans modifier les données.
- Les options **Parcours guidés**, **Aides contextuelles** et **Options avancées** restent disponibles séparément dans Affichage.
- Ajoute un composant partagé de parcours guidé réutilisable par Hub/CRM et les futurs modules.
- Ajoute les règles Mémoire `AWM-UX-DISPLAY-MODES-001` et `AWM-CLIENT-WORKSPACE-001`; seed `2026-10-19.7`, 108 règles.
- Architecture AWM et Revue Futur passent à `2026-10-19.7`.
- Aucun statut client, campagne, lead, facture, Connector ou permission métier n est modifié par un changement de mode d affichage.

## 2026-10-15 - 4.5.293 / Suite AWM 4.5.415 - loi Capturia automatique + seed Mémoire versionné

- Ajoute la règle critique `AWM-CAPTURIA-AUTO-ALL-FORMS-001` : quand Capturia VMV-NAT est actif, tout formulaire capturé du site principal est routé automatiquement, sauf mapping explicite vers une autre campagne.
- Ajoute `AWM-SUITE-PACKAGING-SAFETY-001` après l incident 4.5.413 : aucun arbre de travail ne doit entrer dans un ZIP Suite publié.
- Corrige le mécanisme de seed : `SEED_VERSION` passe à `2026-10-15.4` afin que les nouvelles lois ajoutées depuis 4.5.411 soient réellement importées dans une base Core déjà initialisée, sans réécrire les règles existantes.
- Architecture et Revue Futur passent à `2026-10-15.4`.

## 2026-10-15 - 4.5.292 / Suite AWM 4.5.413 - loi multi-formulaires Capturia et diagnostic par lead

- Ajoute la regle critique Memoire `AWM-CAPTURIA-FORM-SOURCES-001`: un moteur de formulaire explicitement cable et supporte ne doit jamais etre ignore par le routage Capturia VMV-NAT.
- Memoire AWM embarquee: 104 regles.
- Architecture AWM passe a `2026-10-15.3` et formalise le circuit Elementor / Gravity Forms / Contact Form 7 -> VMV-NAT -> Capturia -> preuve technique LeadTracker.
- Le canal Core `client/forms/capturia-delivery` transporte maintenant source, identifiant du formulaire, phase et curseur de notes, toujours sans PII.
- La regle d heure canonique existante est appliquee au diagnostic LeadTracker: stockage UTC, affichage America/Toronto HAE/HNE.
- Revue Futur `2026-10-15.3`: prochaine nouveaute prioritaire proposee, matrice de sante des sources et alertes recu-sans-preuve.
- Aucun lead, envoi Capturia, migration ou deploiement distant n est execute par Core a l installation.

## 2026-10-15 - 4.5.291 / Suite AWM 4.5.412 - Architecture du pipeline CRM et loi de provenance

- Met à jour **Architecture AWM** vers `2026-10-15.2` : CRM AWM devient explicitement la source de vérité des opportunités et de leur état commercial.
- Ajoute le flux transversal **Interaction CallTracker → opportunité CRM** : création explicite, référence source stable/idempotente, pipeline CRM, issue Gagné/Perdu.
- Ajoute la règle Mémoire `AWM-CRM-OPPORTUNITY-SOURCE-001`; la Mémoire Core contient maintenant 103 règles embarquées.
- Le déplacement d une opportunité ne peut jamais modifier le lead/appel/formulaire source, la campagne, le CPL ni sa qualification opérationnelle.
- La revue Futur `2026-10-15.2` confirme le pipeline CRM 1.6.33 comme vraie nouveauté de cette Suite et conserve les prochaines nouveautés de chacun des dix modules.
- Aucun lead, opportunité, campagne, facture, CPL ou statut n est créé/modifié par Core à l installation.
- Les routes de sous-menu WordPress restent enregistrées conformément à la règle de stabilité 4.5.403.

## 2026-10-15 - 4.5.290 / Suite AWM 4.5.411 - Mémoire, architecture et revue Futur obligatoires

- Ajoute **Core > Outils avancés > Architecture AWM**, un registre en lecture seule et exportable des responsabilités, sources de vérité, frontières de stockage, flux critiques et dépendances de la Suite.
- Ajoute un snapshot **Revue Futur** couvrant les dix modules : maintenance/correctifs, améliorations et vraies nouveautés, recoupé avec la roadmap publique consultée en direct avant le build.
- Ajoute les règles Mémoire `AWM-ARCHITECTURE-SOURCE-001`, `AWM-SUITE-FUTURE-REVIEW-001` et `AWM-CAPTURIA-CRM-PII-001`; le seed passe à `2026-10-15.1` sans réécrire les révisions existantes.
- Les futures publications de Suite, une fois Core 4.5.290 actif, doivent déclarer `architecture_contract` et `future_review` dans leur manifeste, avec couverture des dix modules et URL de roadmap publique Alliance.
- Architecture Capturia clarifiée : Capturia reçoit les données personnelles utiles du prospect VMV-NAT; seule la table de preuve AWM reste PII-free.
- Aucun connecteur, campagne, CPL, prospect, déploiement distant ou migration métier n est lancé par cette version. Seul Core change.

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

- Ajoute le canal Connector authentifié `client/forms/capturia-delivery` pour recevoir du site Vendre Maison Vite une preuve technique PII-free après l envoi d un formulaire VMV-NAT vers Capturia.
- Core vérifie le client, le site appairé et l instance avant de transmettre le reçu à LeadTracker; aucune clé Capturia ni donnée nominative n est incluse dans ce reçu.
- Le canal ne crée ni contact, ni campagne et ne modifie aucun CPL. Les outils et la clé API Capturia restent centralisés dans Core.
- Mémoire de développement : règle `AWM-CAPTURIA-PROOF-ARCHIVE-001` ajoutée; les règles existantes sont conservées.

## 2026-10-15 - 4.5.288 / Suite AWM 4.5.405 - Capturia dans Core

- Ajoute **Capturia - Vendre Maison Vite** dans `Core AWM > Connexions > Coffre et cles`.
- La nouvelle cle API peut etre remplacee directement dans Core, sans trousseau v2 obligatoire pour cette operation; elle reste chiffree au repos par le coffre Core existant.
- Bouton de test en lecture uniquement (`/me`, un contact, une source); aucune ecriture fournisseur durant le test. Les scopes d ecriture sont seulement detectes et affiches.
- La cle n est jamais reaffichee ni journalisee. Capturia reste strictement limite a Vendre Maison Vite.
- La connexion peut ensuite etre promue dans le trousseau v2 lorsque celui-ci est prepare.
- LeadTracker 1.11.56 lit cette cle Core en priorite et conserve l ancienne cle par campagne uniquement comme repli de compatibilite.
- Aucun lead, CPL, source Capturia, campagne ou statut commercial n est modifie lors de l installation.

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

Canal CRM client prive dans Core, sans stockage metier parallele; garde client/site/instance/autorisation et chiffrement Core existant.

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.

---

## 2026-10-14 - Core 4.5.286 / Suite 4.5.403 - Acces aux mises a jour retabli

- Regression 4.5.285 reproduite : compact_menu retirait les routes secondaires de `$submenu`. Le parent WordPress devenait vide et le hook recherche ne correspondait plus au callback enregistre, causant un faux refus d'acces.
- Toutes les routes enregistrees restent dans le registre WordPress. Le menu conserve cinq rubriques visibles; seules les lignes secondaires du menu lateral sont masquees par une classe CSS.
- Les permissions, callbacks, nonces, moteurs de mise a jour, import par paquets et Recovery ne sont pas modifies. Les extensions tierces du menu restent visibles.
- Secours distinct `awm-core-menu-rescue` 1.0.0 : restaure temporairement le menu complet uniquement sur Core 4.5.285, sans installer Core, sans ecriture metier et sans neutraliser les protections d'installation. Inerte sur 4.5.286.
- Memoire : nouvelle regle AWM-CORE-NAV-ROUTES-001; 95 regles precedentes preservees; seed 2026-10-14.3; schema DB inchange.
- Tests locaux de routage/permissions et rendu de l'import. Pas de validation sur WordPress Alliance, ni de deploiement ou de restauration SQL reels. Roadmap publique non verifiee.

---

## 4.5.402 / Core 4.5.285 - 14 octobre 2026
- Navigation en cinq espaces, sous-navigation contextuelle, fil d'Ariane et recherche d'outils locale, filtrée selon les droits.
- Accueil orienté tâches; anciennes URL et diagnostic détaillé conservés.
- Écrans Connexions, Utilisateurs et accès, Modules et mises à jour, Outils avancés guidés.
- L'état du coffre est présenté comme un état de stockage, jamais comme une preuve de connexion fournisseur.
- CSS Core seul : panneaux, cartes et textes harmonisés en clair/sombre; Mémoire AWM lisible, filtres accessibles, focus clavier et tableaux défilants dans leur propre zone.
- Rendement : le rendu de l'accueil n'appelle plus l'inventaire clients ni le bilan Health; le coffre ne charge plus les 500 clients de l'écran d'approbation. Les traitements admin_init existants ne sont pas modifiés et aucun gain chronométré en production n'est revendiqué.
- Protections et actions existantes conservées; règle AWM-CORE-UX-001 ajoutée sans réécriture des 94 règles antérieures.
- Tests locaux : 140 assertions PHP avec doubles WordPress/SQL, 150 configurations de rendu (15 pages x 2 thèmes x 5 largeurs), 18 interactions, 32 mesures de contraste ciblées. Syntaxe runtime : 140 PHP / 25 JavaScript / 128 JSON.
- Essai WordPress réel, import, connexions fournisseurs, appareils réels et publication publique restent à confirmer.

---

## Historique conservé

## 4.5.401 / Core 4.5.284 - 2026-10-14 - candidat local

- Nouveau service Core de chiffrement authentifié XChaCha20-Poly1305, sous-clés séparées par installation/client/usage et authentification du contexte d'enregistrement. Pas de repli v2 vers les sels ou l'URL WordPress.
- Trousseau versionné externe, source fichier privé hors racines Web ou environnement serveur. Aucune clé dans le paquet. Outil CLI de création/rotation avec conservation des anciennes clés.
- Migration administrative des configurations globales `callink_twilio_settings`, `callink_google_ads_settings`, `callink_google_ads_tokens`. La configuration complète est chiffrée dans une option Core; l'ancienne option devient une référence opaque. Relecture et comparaison avant bascule conditionnelle pour ne pas écraser une modification concurrente.
- Adaptateur compatible avec les lectures et renouvellements OAuth existants. Protection du premier add_option et du double passage des sanitizers; aucune réponse HTTP de lecture de secrets ajoutée.
- Gestion réservée aux administrateurs Core, POST et nonce, confirmations de sauvegarde et de restauration. Clé absente, secret altéré ou référence corrompue : lecture bloquée, écriture refusée sans remplacement silencieux.
- Index HMAC d'identité par client disponible comme primitive interne, stable lors d'une rotation des clés de chiffrement. Aucune table de prospects, normalisation d'identité ni déduplication métier livrée ici.
- Anciennes versions de connexions conservées chiffrées au moins sept jours; nettoyage explicite borné, jamais des références courantes ou des clés du trousseau.
- Six règles ajoutées à la mémoire de développement Core; les travaux non implémentés sont marqués comme exigences cibles.
- Ancien codec v1, moteurs d'import/déploiement, droits existants et dix autres ZIP inchangés. **Ne pas changer les anciennes clés/sels; ne pas revenir à un ancien Core après migration sans restauration cohérente.**

---

## 4.5.283 — Connecteur Capturia existant pour le site principal VMV — 2026-10-12
- Route Connector POST authentifiée par secret de site, site_id, instance_uuid, client CRM actif et URL canonique, réservée au site principal et à VMV-NAT (SEO).
- Provisionnement temporaire de la clé Capturia existante depuis le Vault pour Hub Client 1.14.21 ; jamais exposée au navigateur, journalisée seulement par identifiants non sensibles.
- Aucun changement aux comptes, clients, secrets historiques Google Ads ou modules Tech.

## 4.5.282 — LeadTracker et autorisation CRM Client AWM — 2026-10-07
- Met à jour les libellés visibles CallTracker vers **LeadTracker AWM** sans changer le slug technique `calltracker`.
- Ajoute l onglet central **Câblage des leads** au shell LeadTracker.
- Ajoute le endpoint Connector authentifié `client/modules/status` pour informer Hub Client des modules appliqués au client.
- Autorise ce statut par les transports Connector de secours sans exposer de secret au navigateur.

## 4.5.281 — état local fiable et réinstallation de build identique — 2026-10-06
- Corrige le faux état **100 % / À jour** lorsqu’un module porte déjà le bon numéro de version mais n’a aucune empreinte de build locale vérifiée.
- Une version identique avec empreinte inconnue est désormais classée **Build à vérifier** et reste actionnable dans **Mettre à jour Alliance**.
- La réinstallation du paquet signé de la publication est autorisée pour une version identique lorsque le build local est inconnu ou différent; sauvegarde locale, SHA-256, validation de version et réactivation restent obligatoires.
- Réserve la barre **100 %** aux modules dont le numéro et le build sont réellement vérifiés.
- Prépare la republication forcée de CallTracker 1.11.37 afin que le correctif Capturia soit installé même si un ancien build 1.11.36 est déjà présent.

## 4.5.280 — import Suite déterministe par manifeste — 2026-10-05
- La publication d’une Suite sélectionne d’abord le fichier ZIP exact déclaré dans `manifest.modules.<slug>.file`.
- Un ancien ZIP résiduel portant le même préfixe ne peut plus être choisi avant le paquet attendu par simple ordre de `glob()`.
- La garde stricte version ZIP = `manifest.modules.*.version` = `roadmap_sync.versions.*` reste active.
- Corrige le rejet observé avec Suite 4.5.358 lorsqu’un paquet Core/CallTracker plus ancien coexistait par erreur dans l’archive.

## 4.5.279 — roadmap publique CPL provenance 1.11.32 / Hub 4.5.67 — 2026-10-05
- Publie la correction historique Google Ads des lignes CPL legacy à 7 %, la priorité aux valeurs manuelles et le correctif CSS Historique CPL.

## 4.5.278 — roadmap publique CPL complet CallTracker 1.11.31 / Hub 4.5.66 — 2026-10-04
- Synchronise `/hub/roadmap/` avec le lot **CPL complet** de CallTracker AWM 1.11.31 et Hub AWM 4.5.66.
- Publie le statut mensuel **Complet / Complet · 0 lead / À compléter** avec source, devise, fraîcheur et dernière erreur Google Ads.
- Publie les paramètres mensuels par campagne : rabais, réceptionniste et autres coûts avec application automatique aux nouveaux mois.
- Documente la conservation de la provenance Google Ads lorsqu un administrateur modifie uniquement les frais annexes; un changement manuel de l investissement devient explicitement `manual_override`.
- Publie la synchronisation Google Ads de toutes les campagnes mappées avec progression de cycle en arrière-plan.
- Conserve la formule AWM du CPL et les 214 appels historiques manquants comme écart connu non bloquant.

## 4.5.277 — roadmap publique CallTracker 1.11.30 — 2026-10-04
- Synchronise `/hub/roadmap/` avec le correctif UX CallTracker 1.11.30.
- Publie la suppression du **Modification groupée** natif WordPress sur le CPT Campagnes.
- Publie le bouton **Actions groupées** dans la barre Recherche / filtres et le panneau pleine largeur hors tableau.
- Confirme que le moteur métier sécurisé 1.11.29 reste inchangé.
- Conserve les 214 appels historiques manquants comme écart connu non bloquant.

## 4.5.276 — roadmap publique CallTracker 1.11.29 — 2026-10-04
- Synchronise `/hub/roadmap/` avec CallTracker 1.11.29.
- Publie les actions groupées guidées de Campagnes : Activer, Pause et Réattribuer avec aperçu serveur.
- Documente les opérations sensibles Archive/Corbeille/Libérer Twilio/Suppression définitive comme parcours séparé avec confirmation et garde-fous.
- Marque le tri métier et les vues technicien 1.11.28 comme validés terrain par l exploitation.
- Conserve les 214 appels historiques manquants comme écart connu non bloquant.
- Aucun changement d API Connector, Vault ou Recovery.

## 4.5.275 — roadmap publique CallTracker 1.11.28 — 2026-10-04

- Synchronise `/hub/roadmap/` avec CallTracker 1.11.28.
- Publie le tri serveur Leads 30 j / Historique total / CPL et les vues technicien mémorisées.
- Conserve les 214 appels historiques manquants comme écart connu non bloquant.
- Aucun changement de permissions, API, Connector, Vault ou Recovery.

## 4.5.274 — historique total CallTracker + roadmap publique — 2026-10-04
- Synchronise `/hub/roadmap/` avec CallTracker AWM 1.11.27 et la nouvelle lecture **Historique total** dans Campagnes.
- Classe l affichage historique par campagne comme **Livré** : totaux appels + formulaires visibles même lorsque les 30 derniers jours sont à zéro.
- Reclasse les 214 appels historiques manquants comme **écart connu non bloquant**, conformément à la décision opérationnelle de poursuivre sans réparation immédiate.
- Met à jour le registre de repli des versions publiques : Core 4.5.274, Hub 4.5.65, CallTracker 1.11.27, Hub Client 1.14.17 et Tech 1.10.5.

## 4.5.273 — validation terrain formulaires historiques + roadmap publique — 2026-10-04
- Marque comme validé sur le terrain le correctif CallTracker 1.11.26 du cas témoin VMV-NAT : vrai courriel prospect, téléphone et page source.
- Synchronise `/hub/roadmap/` avec la réintégration historique : 44 712 formulaires présents, 69 092 appels présents sur 69 306 et 214 appels encore à réparer.
- Ajoute dans la roadmap publique CallTracker la correction des coordonnées historiques comme **Livré** et la réparation ciblée des 214 appels comme **Maintenant**.
- Met à jour le journal et les notes de Suite sans modifier CallTracker 1.11.26 ni les autres composants métier.

## 4.5.272 — shell CallTracker pour le dashboard — 2026-10-02
- Classe `callink-dashboard` dans le module CallTracker au lieu du repli générique Hub.
- Ajoute **Tableau de bord** comme premier onglet du header CallTracker et étend le sous-titre aux formulaires.
- Met à jour la roadmap publique CallTracker pour refléter le dashboard clients/campagnes et les corrections terrain 1.11.20.

## 4.5.271 — collecte formulaire depuis status — 2026-10-01
- Persiste `form_inventory` lorsqu un `update/status` Hub Client est déjà demandé par Core.
- La vérification fraîche après mise à jour Hub Client stocke immédiatement les formulaires détectés, sans attendre le prochain push horaire.
- Le rafraîchissement demandé par CallTracker reste séquentiel et réutilise le verrou d inventaire par site de Core 4.5.269.

## 4.5.270 - inventaire formulaires site-scoped - 2026-10-01
- La route d inventaire Hub Client accepte aussi l inventaire formulaires et le délègue à CallTracker après authentification du Connector.
- Aucun nouvel appel réseau n est créé; l inventaire formulaires est piggybacké sur la synchronisation existante.

## 4.5.269 - 2026-10-01
- Protection anti-rafale : un seul site par lot Autopilote et delai de 2 s entre les sites.
- Verrou/deduplication d inventaire par site : une seule requete distante simultanee par installation WordPress.
- Les refresh concurrents reutilisent l inventaire connu au lieu de multiplier les appels.
- Le suivi navigateur apres lancement Autopilote devient sequentiel, sans setInterval chevauchant.
- Recuperation JSON robuste face aux BOM/warnings/HTML parasites autour d une reponse valide, sans accepter une reponse vide.

## 4.5.268 - 2026-10-01
- Remplace le transport manuel préféré des paquets distants par un ZIP statique éphémère servi directement par le serveur web, afin d’éviter les réponses binaires vides et HTTP 503 observées sur certains WAF/proxy.
- Le paquet est déchiffré puis vérifié localement avant publication temporaire; sa taille et son SHA-256 doivent être valides avant que l’URL soit transmise au Connector.
- L’URL éphémère contient 256 bits aléatoires, les anciennes copies sont nettoyées automatiquement, et le Connector conserve la vérification SHA-256 avant toute installation.
- Les anciens transports admin-post, REST, admin-ajax et frontal restent disponibles comme replis; `static` devient aussi le premier repli explicite.
- Recovery reste temporairement hors du chemin bloquant et demeure inscrit au roadmap futur pour une réintégration asynchrone non bloquante.

## 4.5.267 - 2026-10-01
- Transport paquet multi-endpoint signé.

## 4.5.266 — 2026-10-01
- Réessaie automatiquement le transport REST signé lorsqu’un déploiement manuel reçoit `awm_update_download_empty`, en plus du repli HTTP 503 existant.
- Correctif ciblé du cas Vendre Maison Vite / VMV-GADS sans modifier la politique flotte ni réintroduire Recovery comme garde bloquante.

## 4.5.265 — 2026-10-01
- Recovery reste installé et administrable, mais sa garde n est plus bloquante pendant la stabilisation de la flotte.
- L Autopilote enchaîne Hub Client, Tech et les mises à jour sans attendre `recovery_ready_for_auto`.
- Les protections HMAC, SHA-256, sauvegarde locale, rollback, validation de version et no-downgrade restent actives.
- Le statut flotte revient à `À jour` lorsque Hub/Tech/modules sont conformes; les états `Recovery requis/bloqué/en préparation` sont retirés du parcours normal.
- Recovery est inscrit au roadmap futur pour réintégration comme certification indépendante, sans blocage du worker principal.

## 4.5.264 — 2026-10-01
- Recovery de flotte devient asynchrone : Core demarre un job local persistant sur chaque site et passe immediatement au suivant.
- Le worker central ne reste plus bloque jusqu a 2100 secondes par site; il relit les jobs Recovery par passages courts jusqu a certification.
- Les sites en cours affichent `Recovery en preparation` sans etre comptes comme bloques; la file se reboucle automatiquement tant que des certifications sont en cours.

## 4.5.263 — 2026-10-01
- Affiche `À jour · Recovery certifié` seulement lorsque Hub, Tech et la preuve Recovery sont confirmés.
- Un site sans mise à jour mais non certifié affiche `Recovery en préparation` au lieu d un faux `À jour`.
- La flotte peut certifier les bases MySQL partagees via Hub Client 1.14.8 / Recovery 1.2.5.

## 4.5.263 — 2026-10-01
- Politique Tech simplifiee : Tech est actif par defaut pour tout client valide; seule la meta CRM explicite `_awm_thech_enabled=0` bloque l installation ou la reactivation.
- Core ne delegue plus cette decision a la resolution du module Tech pendant le bootstrap, supprimant le faux `Tech a installer` observe sur Climat NordSud.
- Tech manquant, inactif **ou plus ancien que la publication active** est installe/active/mis a niveau avant toute verification Recovery. Recovery ne peut donc plus bloquer la mise a niveau de Tech lui-meme.
- Les inventaires frais sont fusionnes en mode anti-regression : une ancienne telemetrie ne peut plus remplacer une version Hub Client/Tech deja confirmee plus recente.
- La chaine cible devient Hub Client -> Tech courant et actif -> Recovery -> autres mises a jour, avec fail-closed uniquement a partir de Recovery.

## 4.5.260 — 2026-10-01
- Correction terrain : la page **Sites connectés** et le worker Autopilote utilisent désormais le même critère de site connecté.
- Un Connector `state=connected` est traité même lorsque `runtime_authorized` n est pas encore persisté à `1`.
- Corrige l arrêt observé après 4 sites alors que 15 sites étaient visibles : le worker ne considère plus la flotte terminée prématurément.
- Les clients non opérationnels et les Connectors réellement déconnectés restent exclus.
- Les gardes Hub Client, Recovery, HMAC, SHA-256, rollback et no-downgrade restent inchangées.

## 4.5.259 — 2026-10-01
- Corrige l arrêt de la file Autopilote après quelques clients : chaque lot de continuation est maintenant planifié avec un jeton cron unique pour empêcher la déduplication silencieuse de WordPress.
- Le prochain lot est planifié à échéance immédiate avant `spawn_cron()`, afin qu il soit réellement exécutable dans le loopback courant au lieu d attendre une future visite du site.
- L état du worker reste `queued` entre deux lots et ne repasse à `idle` qu à la fin réelle du cycle complet.
- La relance Recovery et la continuation de flotte utilisent un seul dispatch immédiat; aucun double événement n est nécessaire.
- Recovery reste fail-closed par site et un échec isolé ne bloque pas les clients suivants.

## 4.5.258 — 2026-10-01
- Corrige la continuation de l Autopilote : le lot suivant n est plus dispatché pendant que le verrou du lot courant est encore actif.
- Le clic **Lancer l Autopilote maintenant** amorce désormais une vraie file persistante avec la taille de lot normale au lieu de ne traiter qu un seul site.
- La file se relance immédiatement après libération du verrou et ne dépend plus d un rechargement de la page admin ni d une visite WordPress pour continuer.
- Suppression du `location.reload()` automatique après le premier lot; l écran rafraîchit silencieusement les sites sélectionnés pendant que le worker continue en arrière-plan.
- Recovery reste fail-closed site par site; un site bloqué ou en erreur n interrompt pas le passage aux sites suivants.

## 4.5.257 — 2026-10-01
- Parcours Autopilote Recovery **zero-clic** : Hub Client est repare/reconcilie automatiquement avant Recovery, y compris si `update/status` refuse temporairement la commande ou si une transaction MU reste en attente.
- Si Hub Client est derriere la publication active, Core le remet d abord a niveau avec backup/rollback et verification dans une nouvelle requete, puis reprend automatiquement Recovery.
- Recovery est ensuite repare, son perimetre objectif est valide, un point complet est cree et le vrai test fichiers + SQL est lance automatiquement. L installation de Tech et des autres mises a jour reprend uniquement apres `recovery_ready_for_auto=1`.
- Le bouton de lot devient **Reparer la selection** : il lance le parcours complet au lieu d exposer Recovery comme une tache separee.
- Aucun site n est declare pret sur une simple tentative : les preuves route, scope, checkpoint, restauration SQL/fichiers et nettoyage restent obligatoires.

# Changelog Core AWM

## 4.5.256 — 2026-10-01
- UX Recovery mise a jour pour le fallback SQL mutualise : base distincte si disponible, sinon sandbox de tables isolees dans la base WordPress.
- La preparation Recovery en lot conserve le fail-closed et reprend l Autopilote uniquement apres une preuve de restauration valide.
- Les messages administrateur ne demandent plus de creer manuellement une base temporaire lorsque le privilege CREATE DATABASE manque.

# 4.5.255 — 2026-10-01

- Roadmap publique Suite 4.5.319.
- Synchronise /hub/roadmap avec l UX Campagnes Appels/Formulaires, le pilotage Elementor/Gravity Forms depuis Alliance et la suppression logique sécurisée des fiches clients CRM.

## 4.5.254 - Autopilote Recovery auto-réparable + préparation en lot - 2026-09-30
- L Autopilote tente maintenant `tech/recovery/prepare` avant tout déploiement Hub Client/Tech : réparation de route et rafraîchissement des preuves sans contourner Recovery.
- Si le périmètre de sauvegarde a déjà été confirmé par un administrateur mais que le vrai test n est plus valide, Core relance automatiquement le test isolé fichiers + SQL dans une base temporaire distincte.
- Dès que `recovery_ready_for_auto=1`, la mise à jour reprend dans le même passage Autopilote; aucune action manuelle « Déployer » n est nécessaire.
- Si la confirmation du périmètre manque, le site reste fail-closed avec le statut explicite « Confirmation administrateur du périmètre Recovery requise une seule fois ».
- Ajoute **Préparer Recovery** pour la sélection : une seule confirmation de vague, puis validation indépendante de chaque site; un site bloqué n arrête pas les autres.
- Une préparation Recovery réussie relance automatiquement le worker Autopilote.
- Corrige aussi le traitement des réponses `ok=false` de la route Recovery : Core les affiche maintenant comme blocage réel au lieu de retourner un faux succès AJAX.
- Aucun bypass de `recovery_ready_for_auto`, aucun assouplissement HMAC/SHA-256, `site_id`, Vault, no-downgrade ou rollback.

## 4.5.253 - Bootstrap de reparation du transport par paquets - 2026-09-30
- Conserve integralement le transport Suite par paquets XHR de 512 Ko de 4.5.252, sans iframe.
- Documente un paquet de secours AWM Core Packet Bootstrap, installe comme extension distincte puis active une seule fois pour remplacer Core lorsque le garde Recovery de l ancien Core bloque son propre remplacement via l installateur WordPress.
- Le garde Recovery reste fail-closed pour les modules AWM ordinaires; aucune autorisation generale de remplacement natif n est ajoutee.
- Le message de blocage Core dirige maintenant vers le paquet Bootstrap plutot que vers une intervention SFTP.

## 4.5.252 - Import par paquets XHR sans iframe - 2026-09-30
- Le téléversement Suite/module est découpé en paquets de 512 Ko et envoyé exclusivement avec XMLHttpRequest.
- Le chemin principal vise `admin-ajax.php` calculé depuis l origine exacte de la page wp-admin ouverte; un troisième essai XHR same-page reste disponible sans iframe.
- Le transport iframe a été retiré du code de l importeur : aucun `contentDocument`, `contentWindow.document`, formulaire ciblé vers iframe ou lecture cross-origin n est utilisé.
- Les paquets sont assemblés côté serveur puis vérifiés par taille et SHA-256 avant traitement AWM.
- La limite passe à 512 paquets, soit toujours 256 Mo maximum, sans modifier les règles de manifeste, documentation, dépôt ou no-downgrade.

## 4.5.251 - Televersement attache a la page wp-admin - 2026-09-30
- Corrige le cas terrain ou `admin-post.php` redirige encore vers `www` malgre une page `wp-admin` ouverte sur le domaine nu.
- Les phases `init`, `chunk` et `finalize` sont maintenant POSTees sur l URL exacte de la page **Mises a jour** deja ouverte (`admin.php?page=...`) via un endpoint `admin_init` prive.
- Le transport navigateur n utilise plus l iframe en dernier recours : trois essais XHR same-page evitent toute lecture `frame.contentWindow.document` et donc toute erreur cross-origin.
- Le handler same-page reutilise `guard_admin()`, le nonce `awm_core_updates`, les blocs de 1 Mo, le SHA-256, les limites de taille et le meme stockage temporaire.
- Les routes historiques `admin-post` / `admin-ajax` restent en place pour compatibilite, mais le tableau de bord n en depend plus pour cet import.

## 4.5.250 - Televersement Suite same-origin - 2026-09-30
- Corrige l import Suite/module quand WordPress canonise `www.alliancewebmarketing.ca` alors que l administrateur est ouvert sur `alliancewebmarketing.ca` (ou l inverse).
- Le transport chunked utilise maintenant `admin-post.php` sur l origine exacte de la page `wp-admin`, ce qui evite le blocage navigateur `Blocked a frame with origin ... from accessing a cross-origin frame`.
- Les deux essais XHR et le fallback formulaire/iframe utilisent le meme endpoint same-origin; nonce, validation, SHA-256, structure et regles no-downgrade restent inchanges.
- Aucun assouplissement CORS et aucun acces cross-origin a l iframe ne sont ajoutes.

## 4.5.249 - Fermeture automatique des transactions v3 supersedees - 2026-09-29
- Corrige `awm_deploy_resume_target_conflict` lorsque Tech AWM ou un autre module conserve une ancienne transaction atomic_v3 vers une version inferieure a la publication courante.
- En intervention administrateur manuelle, Core tente d abord de terminer proprement l ancienne transaction (`activate` si requis, verification runtime, puis `commit`) avant de lancer la cible plus recente.
- Si l ancienne transaction ne peut plus etre terminee, Core execute un rollback lie au `deployment_id`; une nouvelle ecriture ne commence que si cette fermeture est confirmee.
- Les etapes `verified`/`staged` anciennes sont abandonnees sans toucher la version active apres le delai de securite existant de 5 minutes.
- Une transaction visant une version plus recente continue de bloquer tout downgrade; l Autopilote reste fail-closed et Recovery n est jamais contourne.

## 4.5.248 - Hub Client classique unifie - 2026-09-29
- Le fonctionnement normal Hub Client ne depend plus de System Agent, Rescue MU ni d un cutover MU.
- La preuve 1.14.2+ devient simple: plugin actif + version cible + `classic_mode` + `boot_ok` dans une nouvelle requete.
- Le bouton flotte devient **Harmoniser Hub Client** et traite 4 sites en parallele sans arreter la vague lorsqu un site est bloque.
- Core utilise le canal Hub existant en premier, Tech Rescue seulement pour reactiver un Hub desactive, et un System Agent deja present uniquement comme secours de transition.
- Apres confirmation 1.14.2, Core demande au Hub de nettoyer uniquement les anciens artefacts AWM MU connus; les donnees et sauvegardes restent conservees.
- Une ancienne transaction v3 Hub vers une cible precedente est rollbackee avant une nouvelle harmonisation 1.14.2 afin d eviter les transactions imbriquees.

## 4.5.247 - Réharmonisation Hub flotte complète - 2026-09-29
- Remplace le patch System-Agent-only par une harmonisation progressive de toute la flotte.
- Si System Agent existe, il reste le canal prioritaire.
- Si l agent manque mais que l ancien Hub répond, Core met Hub à niveau vers 1.14.1; 1.14.1 auto-installe System Agent 2.0.1 au boot suivant.
- Si la route Hub manque, Tech Rescue peut réactiver la copie canonique avant une nouvelle tentative.
- Les sites sans canal sûr restent intacts, mais n arrêtent plus la vague entière.
- Traitement par lots de 3 et preuve finale Hub 1.14.1 + safe_legacy + boot_ok + System Agent.

## 4.5.246 - Patch Hub flotte System-Agent-only - 2026-09-28
- Ajoute l action **Patch Hub flotte** dans Core AWM > Mises à jour.
- La vague utilise exclusivement AWM System Agent MU 2.x; aucun repli Tech, ancien Rescue ou écriture directe Hub n est autorisé.
- Traitement par lots de 2 sites pour accélérer la remise en état sans lancer toute la flotte simultanément.
- Chaque succès exige Hub Client 1.14.0+ confirmé `safe_legacy` + `boot_ok` dans une nouvelle requête.
- Un site sans System Agent ou dont la réparation échoue reste intact et est journalisé comme bloqué.
- Coupe-circuit de vague : arrêt automatique après 3 échecs consécutifs; les sites restants ne sont pas touchés.
- Aucun bypass de `recovery_ready_for_auto`; cette action répare uniquement Hub Client et ne lance pas les mises à jour automatiques de modules.

## 4.5.245 - AWM System Agent / reprise hors Hub - 2026-09-28
- Ajoute un canal `awm-system-agent/v1` prioritaire au secours Tech lorsque Hub Client est complètement coupé.
- Core peut installer puis activer Hub Client 1.14.0+ via l agent MU indépendant et le secret de scan existant.
- La vérification 1.14.0+ exige `safe_legacy`, `boot_ok` et une version d agent système, au lieu d une preuve de cutover MU.
- Désactive les anciens pré-armements/cutovers MU pour Hub Client 1.14.0+.
- Si AWM System Agent existe mais refuse/échoue une réparation, Core s arrête et ne réactive pas aveuglément un ancien Hub dangereux.
- Le paquet embarque AWM System Agent Recovery Bridge 2.0.0.

## 4.5.244 - Pré-armement strict / aucune écriture Hub sans garde - 2026-09-28
- Le garde `rescue_legacy` doit maintenant être confirmé avant tout remplacement manuel de Hub Client 1.13.9+.
- Si le Rescue ne peut pas être prouvé, Core bloque AVANT écriture du Hub au lieu de poursuivre vers une requête fatale.
- La réparation d urgence ne lance plus deux pré-armements Rescue dans le même clic.
- Le Rescue 1.1.3 doit produire une preuve `rescue_legacy`; quatre HTTP 200 sans cette preuve ne sont plus considérés comme un succès.
- Aucun bypass Recovery; l Autopilote reste fail-closed.

## 4.5.243 - Garde MU précoce et reprise legacy de secours - 2026-09-28
- AWM Hub MU Rescue passe à 1.1.3 et installe un garde MU chargé avant le loader Hub Client normal.
- Avant une mise à jour Hub Client manuelle 1.13.8+, Core pré-arme ce garde si la preuve MU courante n est pas complète.
- Si le cutover MU échoue encore, Core peut confirmer Hub Client 1.13.8 en état explicite `rescue_legacy` plutôt que de rollbacker immédiatement une version saine.
- La transaction Hub Client est alors fermée via `commit_mode=legacy_rescue`; `mu_deferred=1` reste visible et le rollback historique est conservé plus longtemps.
- Le message de vérification ne prétend plus que la version cible a été atteinte lorsque aucune nouvelle requête ne l a réellement confirmé.
- Aucun bypass Autopilote/Recovery : le mode legacy de secours reste strictement manuel et `recovery_ready_for_auto` vaut faux.

## 4.5.242 - Déblocage des transactions Hub Client awaiting_commit - 2026-09-28
- `Réparer` ne considère plus `update/status` comme une preuve suffisante : une transaction Hub Client `awaiting_activation` ou `awaiting_commit` est terminée avant de déclarer le canal sain.
- Lorsqu une ancienne transaction vise une version inférieure à la publication courante, Core répare/valide/commit cette transaction puis démarre la nouvelle cible dans le même clic `Déployer`.
- Le chemin de reprise Hub Client peut maintenant invoquer AWM Hub MU Rescue avant la vérification finale, y compris lorsque la transaction reprise vise déjà la même version.
- AWM Hub MU Rescue passe à 1.1.2 et dérive sa cible de la transaction v3 au lieu d être figé sur 1.13.0.
- Aucun downgrade et aucune seconde écriture Hub Client ne sont autorisés tant que l ancienne transaction n est pas fermée proprement.
- Le chemin de secours reste manuel; l Autopilote conserve ses gardes Recovery et ne reçoit aucun bypass.

## 4.5.241 - Réparation Hub Client sans dépendre de l inventaire - 2026-09-28
- Corrige le cas terrain où `update/status` répond par une erreur critique WordPress alors que le canal signé `update/apply` reste utilisable.
- Le bouton **Réparer** et la préparation d un déploiement manuel peuvent pousser directement le Hub Client stable signé sans exiger un inventaire valide au préalable.
- Après la tentative, Core relit le site dans plusieurs nouvelles requêtes afin de confirmer la vraie version chargée et éviter toute seconde écriture aveugle.
- Le secours autonome Tech reste prioritaire lorsque la route Hub Client est totalement absente.
- L Autopilote n utilise pas cette écriture d urgence : `recovery_ready_for_auto` reste obligatoire et aucune garde Recovery n est contournée.

## 4.5.240 - Rétablissement du canal de mise à jour Hub Client - 2026-09-28
- Ajoute un secours serveur-à-serveur via Tech AWM 1.10.3 quand `awm-client-hub/v1` est absent.
- L action **Réparer** tente désormais une vraie réactivation Hub Client, puis confirme la route dans une nouvelle requête.
- **Déployer** répare d abord le canal de chaque site sélectionné au lieu d exclure silencieusement les sites en `Hub à réactiver`.
- Le bouton Déployer reste utilisable pour déclencher ce parcours de réparation.
- L Autopilote peut restaurer le canal de gestion si Tech 1.10.3 est déjà présent, puis reprend son analyse normale.
- Les sites encore sur Tech 1.10.2 ou plus ancien demandent une dernière réactivation manuelle de Hub Client; après mise à niveau, le secours devient autonome.
- Aucun bypass Recovery : les écritures automatiques exigent toujours `recovery_ready_for_auto`; les déploiements administrateur manuels conservent leur chemin protégé existant.

## 4.5.239 - Parcours Prepare Recovery depuis Sites connectes - 2026-09-25
- Ajoute l action `Preparer Recovery` par site depuis Core AWM > Mises a jour.
- Met a niveau Hub Client manuellement si necessaire, puis revalide la porte Recovery.
- Le mode complet exige une confirmation administrateur, cree un point complet et tente un vrai test fichiers + SQL dans une base temporaire distincte.
- Aucun bypass : `recovery_ready_for_auto` reste obligatoire avant l Autopilote.
- Si le compte SQL ne peut pas creer une base temporaire, le site reste bloque avec une raison explicite.

## 4.5.238 - Blocages Recovery correctement classes dans l Autopilote - 2026-09-25
- Corrige la telemetrie terrain observee sur Allo Demenagement GADS : un refus Recovery enveloppe dans les donnees d une erreur de verification est maintenant reconnu recursivement comme `Bloque Recovery` au lieu de `erreur`.
- Le compteur `bloquees Recovery` augmente donc correctement et le compteur `erreurs` reste reserve aux vraies erreurs techniques.
- La ligne de site conserve `Recovery requis` mais son aide indique desormais la garde exacte manquante : porte Recovery, integrite de route, perimetre de sauvegarde ou vrai test fichiers + SQL.
- Aucun bypass : `recovery_ready_for_auto` reste obligatoire avant toute nouvelle ecriture automatique. Les deploiements manuels proteges restent disponibles.
- Baseline Suite 4.5.285 preservee : Hub Client 1.13.3, Tech 1.10.2, Hub 4.5.59 et CallTracker 1.10.9/Capturia restent inchanges.

## 4.5.237 - Faux modal Recovery corrige et premier passage Autopilote deterministe - 2026-09-25
- Corrige le modal plein ecran `Recovery requis` qui etait un faux positif UI : le loader Core ne traite plus toute classe CSS generique `.error` comme une notice WordPress.
- Les statuts de lignes utilisent `is-error`; les notices natives restent capturees uniquement lorsqu elles sont de vraies notices/erreurs WordPress au niveau racine.
- Ajoute **Lancer l Autopilote maintenant** : un administrateur peut executer un lot diagnostique d un site sans attendre WP-Cron, tout en conservant toutes les gardes Recovery.
- Si l Autopilote est actif mais n a jamais termine un passage, l ecran Mises a jour lance automatiquement ce premier lot diagnostique une seule fois au chargement.
- Le diagnostic affiche maintenant le dernier declenchement du worker et son statut de dispatch, en plus du dernier passage, installes, bloques Recovery et erreurs.
- Aucun bypass Recovery : `recovery_ready_for_auto` reste obligatoire pour l automatique; le bouton manuel `Deployer` continue d utiliser le chemin protege manual existant.
- Baseline 4.5.284 preservee : Hub Client 1.13.3, Tech 1.10.2, Hub 4.5.59 et CallTracker 1.10.9/Capturia restent byte-for-byte inchanges.

## 4.5.236 - Autopilote explicable et reprise des transactions avant promotion - 2026-09-25
- Le worker Autopilote conserve maintenant un état par site : à jour, en attente, bloqué Recovery, erreur ou version installée.
- La page Core > Mises à jour affiche clairement `Bloqué Recovery` / `Recovery requis` au lieu de laisser une ligne sembler inactive pendant que le worker tourne.
- `update/status` alimente désormais Core avec l état Recovery du site; le heartbeat Connector conserve aussi les preuves `backup_scope`, `restore_test` et `recovery_ready_for_auto`.
- Une transaction atomic_v3 ancienne restée en `verified` ou `staged` est reconnue comme interrompue AVANT promotion : après 5 minutes, Core peut lancer une nouvelle transaction sûre au lieu de bloquer indéfiniment le site.
- Aucun bypass Recovery n est ajouté : l automatique reste fail-closed; les déploiements manuels restent disponibles avec leurs protections existantes.
- Baseline préservée : Hub 4.5.59, CallTracker 1.10.9/Capturia et Tech intervention Elementor restent inchangés fonctionnellement.

## 4.5.235 - Import par blocs visible et transport XHR robuste - 2026-09-24

- Corrige le blocage observe a `Preparation du televersement...` sous Core 4.5.234.
- La requete `init` n attend plus le `load` initial d un iframe `about:blank`.
- Les phases init/chunk/finalize utilisent XMLHttpRequest same-origin vers `admin-post.php`, sans `fetch()`.
- Le troisieme essai conserve un fallback formulaire/iframe, soumis immediatement apres insertion dans le DOM.
- Affiche explicitement le nombre de blocs de 1 Mo, le bloc courant, la progression du bloc, la progression totale, le transport et les reprises.
- SHA-256 navigateur/serveur, nonce, stockage prive, finalisation idempotente et limite de 256 Mo restent inchanges.

## 4.5.234 - Import Suite sans fetch - 2026-09-24
- Remplace le transport `fetch()` de l import Suite/module par un transport HTML natif vers un `iframe` same-origin, toujours en blocs de 1 Mo.
- Chaque bloc passe par `admin-post.php` avec le meme nonce administrateur, puis la reponse JSON est lue depuis l iframe; aucune requete `fetch()` n est requise pour le televersement.
- Conserve trois reprises par phase/bloc, SHA-256 navigateur + serveur, assemblage idempotent, stockage prive et validation finale.
- Ce transport contourne le `Failed to fetch` observe sur Alliance tout en restant sous la limite ModSecurity de 13 107 200 octets par requete.
- Aucun changement aux donnees clients, Capturia, CallTracker, Hub Client, Tech, Recovery ou autopilote.

## 4.5.233 - Import Suite anti-`Failed to fetch` - 2026-09-24
- Reduit les blocs de televersement Suite/module de 4 Mo a 1 Mo afin de mieux traverser les limites proxy/WAF observees sur l import 4.5.275.
- Ajoute jusqu a trois reprises par bloc avec court backoff, puis un transport de repli authentifie via `admin-post.php` si `admin-ajax.php` coupe la connexion.
- Ajoute un timeout explicite de 90 secondes par requete et un diagnostic qui indique la phase/bloc en echec au lieu du seul `Failed to fetch`.
- Rend la phase `finalize` idempotente : une reponse perdue apres assemblage peut etre relancee sans reconstruire ni invalider le ZIP.
- Conserve nonce, permissions admin, taille, SHA-256 navigateur/serveur, stockage prive et validation finale existants.
- Aucun changement aux donnees clients, Capturia, CallTracker, Hub Client, Tech, Recovery ou autopilote.

## 4.5.232 - Worker Autopilote reel et diagnostic de blocage - 2026-09-23
- L activation de l Autopilote declenche maintenant immediatement un worker de fond au lieu de seulement programmer un evenement WP-Cron futur.
- Ajout d un watchdog : si le worker n a jamais tourne ou devient stale, Core replannifie un kick et tente un `spawn_cron()` direct, y compris lorsque le cron visiteur est desactive.
- Etat persistant du worker : dernier depart, derniere fin, duree, prochain passage, nombre installe/bloque/erreur et dernier resultat visible dans Sites connectes.
- L ordre automatique respecte maintenant la dependance critique `Hub Client -> Tech AWM`.
- Les blocages `recovery_ready_for_auto` restent fail-closed et sont comptes explicitement comme `bloque Recovery` plutot que de laisser croire que l Autopilote ne tourne pas.
- Aucun assouplissement Recovery : une mise a jour automatique refusee par le site reste refusee; les actions manuelles gardent leur rollback fichiers local.

## 4.5.231 - interrupteur Autopilote fail-closed - 2026-09-23
- Le badge **Autopilote suspendu / active** de Sites connectes devient cliquable et pilote un etat persistant central.
- L activation exige une publication stable et journalise l administrateur; la suspension est immediate pour les nouvelles operations.
- L autopilote ne contourne jamais Recovery : chaque site execute encore sa garde locale `recovery_ready_for_auto` avant une mise a jour automatique.
- Les sites non prets sont comptes comme bloques Recovery, pas forces ni classes comme erreurs de deploiement.
- Les paquets automatiques signes sont servis uniquement pendant que l autopilote central est active; un jeton auto deja emis est refuse apres suspension.
- Les deploiements automatiques Core sont autorises uniquement depuis le contexte interne de l autopilote; les autres appels implicites restent fail-closed.
- Les actions manuelles Deployer / Forcer sur la selection restent disponibles quel que soit l etat de l autopilote.

## 4.5.230 - Alignement responsive et secours Hub visible - 2026-09-23
- Ancre explicitement chaque cellule de Sites connectes a sa colonne desktop afin qu un statut vide/masque ne decale jamais Mises a jour ni Actions.
- Corrige le selecteur responsive `data-site-update-count` vers le vrai attribut `data-site-updates`.
- Les actions utilisent une grille compacte et restent alignees sous la colonne Actions; elles passent en 2 colonnes puis 1 colonne sur petits ecrans.
- Quand la route privee Hub Client est absente, l etat devient `Hub a reactiver`, un bouton `Reactiver Hub Client` apparait directement dans Actions et Deployer est masque jusqu au retour du canal.
- Les messages identiques `rest_no_route` ne sont plus dupliques dans le journal de la ligne.

## 4.5.229 - Responsive sans barre laterale ni verticale dans Sites connectes - 2026-09-23
- Retire le `min-width` rigide et le `max-height` scrollable de la liste `Sites connectes` de l ecran Mises a jour.
- Passe la grille en disposition fluide sur desktop et en cartes empilees sur tablette/mobile pour eliminer les barres laterale et verticale internes.
- Les cellules Hub Client, Tech AWM, Statut et Mises a jour affichent maintenant leur etiquette en mode compact afin de garder la lisibilite sans en-tete sticky.
- Les actions `Reparer`, `Voir` et `Deployer` se replient proprement et restent accessibles sans debordement.

## 4.5.228 - Reprise v3 independante de la version Connector chargee - 2026-09-23
- Corrige le pilote secondaire GADS bloque en `awaiting_activation`: une version Connector 1.12.x encore chargee ne peut plus masquer une transaction `atomic_v3` valide deja presente sur le site.
- La reprise exige moteur v3, `deployment_id` valide, version cible exacte et etape connue; aucune confiance supplementaire n est accordee a un simple numero de version.
- Une transaction ouverte visant une autre cible bloque toute nouvelle ecriture; `verified` et `staged` interrompus restent fail-closed au lieu de lancer un second paquet.
- Core preserve desormais `mu_runtime_main_ok` et `mu_runtime_tree_ok` lors de la sanitation/inference de l inventaire, ce qui rend la preuve Hub 1.13.0 complete et deterministe.
- Hub Client 1.13.0, Tech 1.8.0 et Recovery restent inchanges; autopilote toujours suspendu.

## 4.5.227 - Reprise v3 avant toute nouvelle ecriture et secours MU rearmable - 2026-09-23
- Core interroge d abord `deployment_transactions` sur les agents atomic_v3. Une transaction `awaiting_activation`, `awaiting_commit` ou `committed` pour la meme cible est reprise avant toute nouvelle installation.
- Une reprise qui ne peut pas etre prouvee reste fail-closed : aucune seconde ecriture disque automatique n est lancee.
- AWM Hub MU Rescue passe a 1.1.1 afin de pouvoir etre republie au-dessus d une ancienne copie 1.1.0 et rearmé sur les sites bloques.
- Si le secours est pose par atomic_v3 avec `activation_pending`, Core execute explicitement `update/activate`, puis force deux requetes PHP fraiches avant la verification Hub.
- Le correctif vise le pilote Demenagement Hull bloque en Hub 1.12.2 / etape distante `awaiting_activation`; Hub Client 1.13.0 et Tech 1.8.0 restent inchanges.
- Autopilote Recovery toujours suspendu.

## 4.5.226 - Deploy Engine v3 et secours MU versionne - 2026-09-22
- Tous les modules AWM declenches manuellement passent maintenant par le chemin transactionnel v3; le moteur historique reste uniquement le repli protege de l automatisation Recovery encore suspendue.
- Une nouvelle extension n est jamais activee en modifiant simplement `active_plugins`: ses hooks d activation sont executes dans une requete PHP fraiche liee au `deployment_id`, puis la preuve runtime et le commit suivent.
- Le preflight ZIP est fail-closed: limite de taille, nombre de fichiers, taille decompressee, chemins dangereux, liens symboliques et ratios de decompression anormaux sont refuses avant extraction.
- Le rollback v3 est idempotent et lie au `deployment_id`; Core refuse de rollbacker une autre transaction par ambiguite.
- Orchestre le nouveau moteur distant `atomic_v3` avec `deployment_id` unique par tentative administrateur.
- Une promotion v3 n est validee qu apres une requete fraiche puis un `update/commit`; un echec de preuve demande un rollback de transaction au lieu de relancer une seconde installation.
- Conserve le meme `deployment_id` lors du repli transport admin-post -> REST afin de rendre la tentative idempotente.
- Embarque le secours interne signe **AWM Hub MU Rescue 1.1.0** pour sortir une migration Hub deja posee sur un chemin PHP fixe et la basculer vers un runtime versionne 1.13.0 sans redemarrage PHP manuel.
- Le secours est distribue uniquement a un site approuve, via URL courte signee, canal Connector HMAC et SHA-256; il s auto-desactive apres la bascule.
- Les controles Vault, `site_id`, permissions, origine HTTPS Alliance et Recovery restent stricts; l autopilote reste suspendu.

## 4.5.225 - reprise des sites deja bloques en Hub Client 1.12.0 - 2026-09-22
- Identifie explicitement `rest_no_route` comme canal Hub Client absent apres migration MU interrompue.
- `Réparer` retourne maintenant le code et les détails du diagnostic au navigateur au lieu d afficher seulement une erreur generique.
- Affiche l action de secours : reactivation de Hub Client AWM dans Extensions du site, puis nouveau `Déployer`.
- Ajoute un lien direct vers `wp-admin/plugins.php` du site concerne sans transmettre de secret.
- Dedoublonne les messages de synchronisation identiques dans le journal de la ligne site.
- Ne relache aucune verification HMAC, SHA-256, site_id, Vault, permissions ou Recovery.

## 4.5.224 - bascule MU sans trou REST - 2026-09-22
- La verification Hub Client 1.12.1+ attend jusqu a cinq lectures fraiches afin de traverser une bascule MU sans conclure sur une seule requete transitoire.
- Le deploiement de flotte arrete les modules suivants d un site lorsque la mise a jour Hub Client de ce site echoue; Tech n est plus tente sur un canal Hub non confirme.
- Le diagnostic `rest_no_route` est identifie comme transition MU possible et conserve le premier diagnostic utile au lieu de multiplier les erreurs secondaires.
- Les controles HMAC, SHA-256, site_id, permissions et Recovery restent inchanges.

## 4.5.223 - bibliothèque distante de modules AWM signée - 2026-09-22
- Expose à Tech un catalogue dérivé exclusivement de la publication Core active pour les modules explicitement autorisés à l installation distante.
- Ajoute `deploy_remote_library_module(client_id, site_id, slug)` : Tech ne choisit ni URL, ni SHA-256, ni version; Core demeure l autorité du paquet.
- Ajoute une signature HMAC `signature_v2` qui lie release, module, version, SHA-256, URL, dossier, fichier principal et politiques d installation/activation.
- Conserve la signature historique en parallèle afin que Hub Client 1.11.52 puisse encore recevoir sa mise à jour vers 1.12.0 sans rupture du canal existant.
- L inventaire Core conserve maintenant les indicateurs MU (`must_use`, `mu_state`, `mu_loader_ok`) remontés par Hub Client.
- Pour Hub Client 1.12.0+, la preuve de déploiement n accepte plus seulement la version : Core relit jusqu à trois requêtes distinctes et exige `must_use=1`, `mu_state=complete` et `mu_loader_ok=1`.
- Autopilote Recovery inchangé et toujours suspendu.

## 4.5.222 - import AWM identifié par le contenu - 2026-09-22
- Corrige le refus `ZIP AWM non reconnu` lorsque le navigateur, ChatGPT ou Windows renomme un paquet valide (`AWM-Suite-...`, `AWM-Core-...`, etc.).
- L import unifié inspecte maintenant le contenu du ZIP : `manifest.json` racine pour une Suite, ou dossier/fichier principal/version interne pour un module.
- Le nom canonique reste accepté en priorité, mais il n est plus l unique source d identité d un paquet.
- Les validateurs spécialisés restent stricts : structure, version interne, documentation, manifeste, roadmap, SHA-256, Vault et permissions ne sont pas assouplis.
- Repli WordPress/PclZip prévu si l extension PHP ZipArchive n est pas disponible.

## 4.5.221 - moteur distant atomique et diagnostic fatal - 2026-09-22
- Abandon du cycle aveugle `Plugin_Upgrader -> activation -> réparation propre` pour Hub Client 1.11.52+ : Core accepte le moteur distant `atomic_v2` et ne relance plus automatiquement une seconde réinstallation destructive.
- Tech n appelle `update/activate` que si le site répond explicitement `activation_pending=1`; le moteur atomique active Tech par l état WordPress sans charger le nouveau runtime dans la requête de remplacement.
- Les erreurs HTTP distantes conservent désormais le code et les données REST d origine.
- La vérification remonte l étape distante, le dernier diagnostic et le fatal PHP nettoyé (`message`, `fichier`, `ligne`) directement dans Core.
- Autopilote inchangé : toujours suspendu.

## 4.5.220 - Activation Tech en deux requêtes PHP - 2026-09-22
- Incident terrain : après Hub Client 1.11.50, le remplacement Tech 1.7.34 -> 1.7.39 peut encore produire une page WordPress « erreur critique » pendant l activation dans la même requête qui contient l ancien runtime en mémoire; la réparation propre peut alors laisser Tech « À installer ».
- Core sépare maintenant installation et activation Tech : `update/apply` pose le paquet, puis `update/activate` est appelé dans une nouvelle requête PHP authentifiée.
- La preuve finale exige Tech présent, plugin actif, runtime version cible chargé et route privée Elementor prête.
- Une activation isolée en échec ne déclenche plus une validation basée uniquement sur la version disque.
- Autopilote inchangé : toujours suspendu jusqu à Recovery complet par site.

## 4.5.219 - Noms de ZIP dupliqués navigateur sans faux changement de version - 2026-09-22

- Corrige le refus `version ZIP attendue 4.5.2481 / manifeste 4.5.248` observé lorsqu'un navigateur renomme un téléchargement en `suite-awm-modulaire-4.5.248 (1).zip`.
- Normalise le suffixe de copie navigateur `(N)` en `-N` **avant** `sanitize_file_name()`, afin de conserver la vraie version sémantique du paquet.
- Applique la même normalisation au téléversement chunked, au téléversement direct, à l'import unifié, à l'import de module et à la publication de Suite.
- La validation manifeste reste stricte : seul le suffixe de copie du nom local est ignoré; `suite_version`, roadmap, versions modules et SHA-256 doivent toujours correspondre.
- Aucun changement au canal HMAC, Vault, permissions, Recovery, déploiement distant ou autopilote.

## 4.5.218 - Transport manuel anti-503 pour les paquets distants - 2026-09-22
- Corrige le pilote Allo Déménagement où Hub Client 1.11.46 et Tech 1.7.34 recevaient HTTP 503 au téléchargement du paquet depuis Alliance.
- Les paquets issus d un clic administrateur manuel utilisent maintenant en priorité un endpoint `admin-post.php` dédié, signé par le même jeton HMAC lié au client, site, release, module, nonce, expiration et mode `manual`.
- Le point manuel refuse tout jeton qui n est pas explicitement signé `manual`; l autopilote et les paquets automatiques restent suspendus par Recovery.
- Si le transport manuel `admin-post` retourne encore HTTP 503, Core effectue un seul repli vers le transport REST signé, puis arrête : aucun cycle infini ni assouplissement de sécurité.
- Journalise le transport réellement utilisé pour faciliter le diagnostic hébergement/WAF sans exposer les secrets.

## 4.5.217 - Intégrité téléversement Suite + manifeste robuste - 2026-09-22
- Calcule le SHA-256 du ZIP côté navigateur avant le téléversement par blocs et le compare au SHA-256 du fichier assemblé côté serveur lorsque Web Crypto est disponible.
- Revérifie l empreinte du ZIP temporaire juste avant l import afin de détecter toute modification entre assemblage et traitement.
- Lit `manifest.json` directement dans l archive ZIP avant extraction; si la copie extraite diverge mais que le manifeste racine de l archive est valide et correspond à la version du fichier, Core utilise la source archive et journalise le repli.
- Remplace le message générique de manifeste par un diagnostic indiquant version attendue, version réellement lue et erreur JSON éventuelle.
- Aucun assouplissement des 10 modules, versions roadmap, SHA-256, permissions, Vault ou garde Recovery.

## 4.5.216 - UI flotte manuelle réellement utilisable - 2026-09-22
- Retire le verrou UI global qui neutralisait encore les actions manuelles malgré Core 4.5.215.
- Réactive **Déployer** par site et **Forcer sur la sélection** pour un administrateur.
- Remplace l état trompeur `Déploiement distant suspendu` par `Autopilote suspendu`.
- Les appels AJAX continuent de passer `manual=true`; aucun déploiement automatique n est réactivé.

## 4.5.215 - Route paquet manuel + migration serveur - 2026-09-22
- Retire le `HTTP 503` inconditionnel de `stream_package()` pour les jetons explicitement manuels et authentifiés.
- Ajoute le mode de déploiement au binding HMAC du jeton de téléchargement afin qu il ne puisse pas être converti de auto vers manuel.
- `deploy_module()` et `rollback_module()` acceptent un booléen manuel; les AJAX administrateur passent `true`, l autopilote conserve le blocage Recovery.
- Ajoute `deployment_mode=manual` aux commandes Hub Client.
- Ajoute un diagnostic de secret Connector illisible après migration serveur sans jamais exposer le secret.

## 4.5.214 - Garde Recovery visible et compteur d erreurs corrigé - 2026-09-21
- Corrige le faux bilan de flotte où chaque refus Recovery était compté comme une erreur de site.
- Désactive les actions de déploiement distant tant que la garde Recovery reste active.
- Affiche `Suspendu` sur les sites ayant des mises à jour en attente plutôt que de lancer des requêtes vouées au refus.
- Conserve Rafraîchir, Voir, inventaire et sélection pour le diagnostic.
- Les vrais échecs restent distingués des suspensions de sécurité.

## 4.5.213 - Grille flotte anti-chevauchement + etat autopilote exact - 2026-09-21
- Elargit la colonne Actions et reserve sa largeur reelle afin que Reparer / Voir / Deployer ne debordent plus sur Statut ou Mises a jour.
- Les actions passent en mini-grille interne et debordent vers la droite uniquement dans la zone de defilement locale si la largeur manque.
- Le tableau flotte conserve un minimum de largeur explicite de 1380 px avec scroll horizontal local.
- Corrige le libelle trompeur Autopilote flotte actif : l UI affiche maintenant Autopilote flotte suspendu tant que le moteur automatique reste volontairement desactive.
- Aucun changement de logique de deploiement, donnees, Connector, inventaire ou CallTracker.

## 4.5.212 - Alignement CSS flotte apres mise a jour - 2026-09-21

- Corrige le decalage des colonnes dans **Sites connectes** observe apres une mise a jour de flotte.
- La grille Hub Client / Tech AWM / Statut / Mises a jour / Actions utilise maintenant des largeurs explicites partagees par l entete et chaque ligne.
- Les badges et statuts sont tronques proprement au lieu de deborder dans la colonne suivante.
- La colonne Actions conserve une largeur fixe suffisante pour Repar­er / Voir / Deployer; si la fenetre est trop etroite, la zone de sites defile horizontalement au lieu de chevaucher les donnees.
- Aucun changement de logique de deploiement, Connector, inventaire, selection ou donnees.

## 4.5.211 - Selection flotte + correctif JS updater - 2026-09-21

- Corrige une regression JavaScript introduite avec le transport par blocs 4.5.210 : le helper `qs` est maintenant initialise avant le premier televersement, ce qui evite l arret du script de la page Mises a jour.
- Le bouton ambigu **Selection manuelle** devient **Tout selectionner / Tout deselectionner** et selectionne tous les sites actuellement visibles selon les filtres.
- Ajoute une case maitre dans l entete de la liste Sites connectes, avec etat coche/partiel synchronise en temps reel.
- Les compteurs de selection restent coherents apres recherche, filtre Principal/Secondaire ou filtre de statut.
- Aucun changement aux Connectors, versions Hub Client/Tech, secrets ou logique de deploiement distant.

## 4.5.210 - Televersement par blocs sous ModSecurity - 2026-09-21

- Corrige le HTTP 500 observe sur `admin-post.php` lorsque ModSecurity refuse un corps multipart superieur a 13 107 200 octets.
- Les ZIP de module et de Suite sont maintenant televerses depuis **Core AWM -> Mises a jour** en blocs de 4 Mo via `admin-ajax.php`, puis assembles dans le dossier temporaire prive avant validation.
- Le formulaire final n envoie plus le gros fichier multipart : il transmet uniquement un jeton temporaire lie a l utilisateur connecte.
- Chaque session de televersement est protegee par nonce, permission Core admin, jeton aleatoire, taille attendue, nombre de blocs, SHA-256 final et purge automatique apres deux heures.
- Les limites metier restent 128 Mo par module et 256 Mo par Suite; le validateur AWM existant reste l autorite finale sur le nom, la version, la structure, README, CHANGELOG, ROADMAP et SHA-256.
- Le mode local 4.5.209 reste conserve : import/depot sans checkpoint Recovery synchrone, backup fichiers avant remplacement local et rollback automatique en cas d echec.
- Recovery fichiers + BD reste separe jusqu au moteur asynchrone afin qu un timeout navigateur ne bloque plus les livraisons.

## 4.5.209 - Mise a jour tableau de bord reparee - 2026-09-21

- L import d un module ou d une Suite dans le depot Core ne lance plus un checkpoint Recovery synchrone : ces actions ne modifient pas le plugin actif.
- Le bouton **Mettre a jour Alliance** utilise le backup local existant de chaque dossier module avant remplacement et conserve le rollback automatique en cas d echec.
- Le garde WordPress autorise uniquement cette transaction locale initiee par Core; les installations AWM hors Core restent bloquees.
- Le chemin fonctionne pour un module seul comme pour les modules d une Suite publiee.
- Recovery fichiers + BD reste separe et suspendu pour les mises a jour locales tant que son traitement asynchrone n est pas livre.
- Le tableau Mises a jour affiche explicitement ce mode pour ne pas faire croire a une preuve de restauration BD.

## 4.5.203 - Secours et points de restauration obligatoires - 2026-09-12

- Isolation des callbacks Health et protection du calcul global contre Throwable; une source defectueuse devient indisponible sans diagnostic invente.
- Nouveau panneau Core > Restauration; moteur CLI externe avec points chiffres fichiers + base, journal hors DB, verification et confirmation explicite.
- Les imports/publications et deploiements locaux exigent une configuration privee et un test de restauration SQL/fichiers sur l'hebergement.
- Autopilote AWM, distribution/deploiements distants et anciennes restaurations fichiers seules sont suspendus. Suite 4.5.231, Core 4.5.202 et CRM 1.6.28 sont bloques comme cibles.
- Depot prive preserve : purge et migration destructive suspendues, nouveaux noms de paquets uniques. Les copies hors serveur du depot externe restent a configurer chez l'hebergeur.
- Aucun rollback DB automatique. Les huit autres modules ne sont pas reconstruits. Lire le guide de secours pour le premier amorcage Core/CRM par SFTP.
- Tests locaux : code reel AWM avec fonctions WordPress doubles, vraie restauration des fichiers et vrai chiffrement; SQL et bootstrap WordPress simules. Validation hebergeur requise.

## 4.5.202 — Pulse v2 et première couche Health AWM — 2026-09-12

- Le contrat Pulse accepte maintenant un score /100, un état de fraîcheur et des raisons courtes, tous assainis par Core.
- Health AWM calcule un score Suite explicable et conserve au maximum 48 instantanés espacés d au moins 30 minutes.
- Aucune note Health ne déclenche une action distante; la règle AWM-HEALTH-PULSE-001 l impose dans la mémoire de développement.

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

- Ajoute le contrat transversal `awm_core_module_pulses` et son rendu dans Santé du système.
- Agrège un pulse explicite pour les 10 modules AWM, dont l état de flotte Hub Client reçu par `fleet_state`.
- Ajoute la règle mémoire AWM-MODULE-PULSE-001 : données compactes, lecture seule, sans secrets ni contenu client brut.

# Core AWM 4.5.200 — publication Suite 4.5.229 / Tech 1.7.32

- **Livré** : registre public aligné sur Tech AWM 1.7.32 et Suite AWM 4.5.229.
- **Livré** : règle `AWM-TECH-OPS-PREFLIGHT-001` pour le préflight Connector / permissions / OPcache, la tournée groupée client + site et la capacité par responsable sans automatisation cachée.
- **Livré** : roadmap publique, changelog, notes et validation/logs synchronisés avant publication.
- **Sécurité** : aucune donnée sensible, chemin serveur, secret Connector ou clé API n est ajoutée au préflight public.

# Core AWM 4.5.199 — publication Suite 4.5.228 / Tech 1.7.31

- Registre public aligné sur Tech AWM 1.7.31 et Suite AWM 4.5.228.
- Nouvelle règle `AWM-TECH-OPS-PRIORITY-001` : la priorité opérationnelle doit rester explicable, ne remplace jamais la criticité brute et les actions suggérées ne doivent pas exécuter de changement sensible sans validation.
- Roadmap publique, changelog, notes et validation/logs synchronisés avant publication.

# Core AWM 4.5.198 — publication Suite 4.5.227 / Tech 1.7.30

- **Livré** : registre public aligné sur Tech AWM 1.7.30 et Suite AWM 4.5.227.
- **Livré** : règle de développement `AWM-TECH-OPS-ACCEL-001` pour les lots accélérés, sondes prioritaires sans hausse du batch, filtres client/site et observabilité fournisseur sans secrets.
- **Livré** : roadmap publique, logs et documentation de livraison restent obligatoires et synchronisés.

## Core AWM 4.5.197 — publication 4.5.226 / Tech 1.7.29

- Registre public aligné sur **Suite AWM 4.5.226** et **Tech AWM 1.7.29** sans rétrogradation des autres modules.
- La roadmap publique documente le diagnostic Wordfence Intelligence V3 non bloquant et la distinction obligatoire entre clé **Account > Integrations** et licence du plugin Wordfence.
- La mémoire de développement ajoute **AWM-TECH-SECURITY-001** : une erreur de fournisseur externe ne doit pas masquer l interface Tech et doit fournir diagnostic + action de correction sans exposer les secrets.
- ROADMAP, CHANGELOG, notes et validation/logs restent obligatoires avant le ZIP final.

## Core AWM 4.5.196 — publication 4.5.225 / Tech 1.7.28

- Registre public aligné sur **Suite AWM 4.5.225** et **Tech AWM 1.7.28** sans rétrogradation des autres modules.
- La roadmap publique documente les alertes/priorités entièrement cliquables, la typographie propagée aux overlays Tech et la personnalisation indépendante du Mode moniteur.
- La mémoire de développement ajoute la règle **AWM-TECH-DASH-006** pour imposer ces comportements dans les prochaines itérations.
- La gouvernance de livraison ajoute **AWM-RELEASE-LOG-001** : ROADMAP, CHANGELOG, notes de livraison et validation/logs doivent être synchronisés avant toute remise de ZIP.

## Core AWM 4.5.195 — publication 4.5.224 et édition Tech sans panneau superposé

- Registre public aligné sur Tech AWM 1.7.27 et Suite AWM 4.5.224.
- Ajoute la règle durable `AWM-TECH-DASH-005` : le panneau Personnaliser se retire pendant le drag & drop et une barre Enregistrer/Annuler reste disponible au bas du dashboard.
- La roadmap publique expose cette amélioration comme livrée et conserve la validation terrain 1080p / 4K comme étape active.
- Aucun changement aux Connectors, `site_id`, `instance_uuid`, secrets, signatures, autopilote ou données opérationnelles.

## Core AWM 4.5.194 — publication 4.5.223, responsive interne et typo des fiches Tech

- Registre public aligné sur Tech AWM 1.7.26 et Suite AWM 4.5.223.
- La règle `AWM-TECH-DASH-004` impose le responsive selon la largeur réelle du bloc et la transformation des tables trop étroites en cartes lisibles.
- La même préférence **Typographie dashboard** doit maintenant suivre jusque dans les fiches Tech, leurs onglets, métriques, SEO, WordPress, sécurité, historique et actions.
- La roadmap publique décrit le dropdown de liens personnalisés, le bouton Fermer compact, les corrections container-responsive et la typographie cohérente des fiches.
- Aucun changement aux Connectors, `client_id`, `site_id`, `instance_uuid`, secrets, permissions ou politiques de déploiement.

## Core AWM 4.5.193 — publication 4.5.222 et shell Tech compact

- Registre public aligne sur Tech AWM 1.7.25 et Suite AWM 4.5.222.
- Le dashboard Tech conserve la grille 12 colonnes, mais les raccourcis personnels sont maintenant integres au shell superieur et Personnaliser devient une icone compacte a cote du bouton Light/Dark.
- Formalise la regle de densite du shell Tech : aucun bloc pleine largeur ne doit etre ajoute uniquement pour les raccourcis ou l action de personnalisation.
- Le panneau Personnaliser doit conserver un contraste natif coherent pour les listes deroulantes en Light et Dark.
- Les contrats Connector, client_id, site_id, instance_uuid, autopilote et signatures restent inchanges.

## Core AWM 4.5.192 — publication 4.5.221 et grille Tech

- Registre public aligné sur Tech AWM 1.7.24 et Suite AWM 4.5.221.
- Formalise dans la mémoire de développement le moteur de grille Tech 12 colonnes, les largeurs ancrées et l adaptation interne des blocs.
- Conserve les contrats Connector, `client_id`, `site_id`, `instance_uuid`, l autopilote et les paquets signés sans changement.
- La roadmap publique reste couplée à `roadmap_sync` et doit afficher Suite 4.5.221 après publication.

## Core AWM 4.5.191 — publication 4.5.220 et roadmap suivie

- Registre public aligné sur Tech AWM 1.7.23 et Hub Client AWM 1.11.44.
- La publication Suite reste l autorité de synchronisation de `/hub/roadmap/` via `roadmap_sync`; aucune livraison n est considérée complète sans cette synchronisation.
- Conserve l autopilote de flotte, les paquets signés, SHA-256, sauvegarde et rollback.

# Core AWM 4.5.190 — registre Suite 4.5.219

- Publie Tech AWM 1.7.22 avec le Mode moniteur fiabilisé pour Chromecast et les actions Tech AJAX.
- Inscrit la règle AWM : lorsqu une action métier peut être actualisée localement de manière sûre, préférer une mise à jour AJAX du bloc concerné au rechargement complet de page.
- Aucun contrat Connector, identité `client_id/site_id/instance_uuid` ou autopilote de flotte n est affaibli.

- Publie Tech AWM 1.7.21 avec la page Réglages unifiée sur le style du Mode moniteur.
- Conserve CRM AWM 1.6.26 et Hub Client AWM 1.11.43 sans rétrogradation.

# Core AWM 4.5.188 — registre Suite 4.5.217

- Publie Tech AWM 1.7.20 avec statuts multi-sites actionnables et actions de fiche alignées.
- Publie CRM AWM 1.6.26 avec une ancre Connector stable pour chaque `site_id`.
- Conserve Hub Client AWM 1.11.43 et tous les mécanismes d autopilote/signature existants.

# Core AWM 4.5.187 — roadmap active et registre 4.5.216

- La section publique **Dernières implantations** est maintenant construite depuis la publication Suite réellement active au lieu de rester figée sur une ancienne version Core.
- `roadmap_sync.release_items`, la date de publication et les versions effectives de la Suite deviennent la source de la première carte publique.
- Le registre publie Tech AWM 1.7.19 et Hub Client AWM 1.11.43 sans rétrograder les autres modules.
- La synchronisation reste compatible avec les promotions directes de modules du dépôt privé.

# 4.5.186 — autopilote central de flotte

- Une publication **Stable** devient l approbation unique pour les modules clients AWM autorisés.
- Core réconcilie automatiquement tous les sites Hub Client actifs et jumelés sans demander de sélectionner les sites.
- Traitement par lots de 2, passage toutes les 5 minutes et relance accélérée après une nouvelle publication.
- Tech AWM est installé/mis à jour avant Hub Client; les contrôles signature, SHA-256, sauvegarde, vérification de version et statut CRM restent inchangés.
- La sélection et le bouton de déploiement restent disponibles uniquement comme forçage manuel.
- Publie Tech AWM 1.7.18 avec Mode moniteur épuré et économiseur d écran.

# 4.5.185 — carte Tech compacte

- Publie Tech AWM 1.7.17 avec en-tête cartographique compact et carte agrandie.
- Registre public aligné sur Tech 1.7.17; Hub Client 1.11.42 et l’autopilote restent inchangés.
- Aucun changement au contrat Connector, aux identités client/site ou aux données opérationnelles.

# 4.5.184 — fiche Tech console opérationnelle

- Publie Tech AWM 1.7.16 avec une fiche site repensée pour la décision rapide.
- Registre public aligné sur Tech 1.7.16 sans modifier Hub Client 1.11.42 ni les contrats Connector.
- Ajoute au suivi public la barre Santé, la zone À faire, les onglets Vue d’ensemble/SEO/WordPress/Sécurité/Historique et les filtres WordPress intégrés.
- Aucun changement de sécurité, secret, identité client/site ou mécanisme d autopilote.

# 4.5.183 — visibilité autopilote flotte

- Registre Hub Client porté à 1.11.42.
- Dans Sites connectés, les mises à jour Hub Client/Tech prises en charge par Hub Client 1.11.42+ sont indiquées **Auto en attente** au lieu de simplement **Prêt**.
- Le bouton Déployer reste disponible comme forçage manuel immédiat.

## 4.5.182 — 2026-09-11
- Publie Tech AWM 1.7.15 avec Mode moniteur en fenêtre dédiée, diagnostic SEO/indexation complet et inventaire WordPress intégré à la fiche Tech.
- Synchronise les couleurs Top sites avec la carte et rend les URL de carte cliquables.
- Conserve Hub Client 1.11.41 et le canal signé Core sans rétrogradation.

## 4.5.181 — 2026-09-11

- Publie Hub Client AWM 1.11.41 avec un autopilote de mise à jour après appairage sur le canal stable Core.
- Publie Tech AWM 1.7.14 avec inventaire complet des extensions WordPress et choix `Manuel / Automatique` par `client_id + site_id + plugin_file`.
- Les modules AWM restent exclus du moteur générique WordPress et continuent exclusivement par le canal Suite signé Core.
- Ajoute les règles durables `AWM-UPDATES-003`, `AWM-TECH-PLUGIN-001`, `AWM-TECH-INDEX-001` et `AWM-TECH-MAP-001`.
- Aligne le registre public des versions sur Core 4.5.181, Hub Client 1.11.41 et Tech 1.7.14.

## 4.5.180 — 2026-09-11

- Core applique désormais le statut CRM canonique à toute autorisation d accès client.
- Un client `inactive` ou `archived` ne peut plus utiliser Connector, sessions Hub/API ni commandes serveur-à-serveur, même si ses secrets et son approbation existent toujours.
- La suspension est réversible : Core ne révoque ni ne régénère le Connector; une réactivation CRM réutilise les mêmes identifiants et secrets.
- Les administrateurs Alliance et les données historiques ne sont pas supprimés ni modifiés par cette garde.

# 4.5.179 — Connector www/apex et contexte compact du shell

- Corrige l appairage Hub Connector lorsque la fiche CRM utilise `domaine.ca` et le WordPress client `www.domaine.ca`, ou inversement.
- Les autres sous-domaines, ports et chemins restent strictement distincts.
- Ajoute les URL canoniques et clés de comparaison au journal interne en cas de refus, sans secret Connector.
- Ajoute un slot de métadonnées compact au shell AWM afin que les modules puissent remonter leur état/version directement dans l en-tête principal.

# 4.5.178 — notices WordPress masquées sur tous les modules AWM

- Étend la détection d'écran AWM à tous les slugs `awm-*` / `awm_*`, incluant Tech AWM et les futurs modules.
- Les bandeaux WordPress, nags de mise à jour et promotions tierces restent masqués sur toutes les pages AWM.
- Les messages métier AWM continuent de passer par `data-callink-loader-result` et le loader AWM; le polling de fond demeure silencieux.
- Corrige notamment les notices tierces qui apparaissaient au-dessus du Centre d'opérations Tech AWM.

## 4.5.177 — 2026-09-09
- Aligne la Suite sur Stats AWM 1.7.0 et son connecteur Screpy serveur-à-serveur.
- Ajoute `AWM-STATS-009` : Screpy est la source technique pour crawler SEO, Quick Wins, Rank Tracker, Core Web Vitals et uptime; AWM interprète ces données au lieu de recréer ces moteurs.
- Fige le contrat sécurité : clé Screpy globale Alliance chiffrée avec Core Vault, jamais exposée côté client.
- Fige l appairage par domaine exact tout en conservant `client_id + site_id + instance_uuid` comme périmètre runtime canonique.
- Aucun secret Connector existant, historique Stats ou donnée CRM n est migré ou supprimé.

## 4.5.176 — 2026-09-09
- Aligne la Suite sur Stats AWM 1.6.2 : la carte Temps réel suit réellement le thème AWM Light/Dark sans clé API externe.
- Ajoute `AWM-STATS-008` pour figer le contrat de thème cartographique et la détection `awm-theme-dark`.
- Corrige l artefact de pixel résiduel des barres de progression Core : une progression à 0 % est réellement retirée du rendu jusqu au démarrage.
- Aucun changement aux Connectors, `client_id`, `site_id`, `instance_uuid`, secrets ou données Stats.

## 4.5.175 — 2026-09-09
- Formalise `AWM-STATS-007` : la carte Temps réel Stats doit fonctionner par défaut sans clé API cartographique externe.
- Aligne la roadmap Suite sur Stats AWM 1.6.1 et son fond OpenStreetMap clair/sombre sans CARTO/Mapbox/Stadia obligatoire.
- Conserve tous les contrats multi-sites, Connector, confidentialité et rafraîchissement silencieux de la 4.5.174.

## 4.5.174 — 2026-09-09
- Aligne la Suite sur Stats AWM 1.6.0, Hub Client 1.11.38 et Hub AWM 4.5.54.
- Ajoute `AWM-STATS-006` : la carte temps réel doit rester utile quand GeoIP est incomplet grâce à un repli approximatif par fuseau, sans GPS/IP, avec qualité de localisation visible et thème clair/sombre.
- Ajoute `AWM-UX-003` : aucun polling, heartbeat, autosave ou rafraîchissement technique de fond ne doit déclencher le loader global AWM.
- Enregistre les premiers signaux Health local-first de Stats 1.6.0 dans le contexte de développement et la roadmap Suite.

## 4.5.173 — 2026-09-09
- Étend l horloge canonique Core avec `period_bounds_utc()` et `local_date()` pour que les modules puissent stocker UTC tout en calculant leurs journées dans `America/Toronto`.
- Formalise la règle Mémoire AWM `AWM-TIME-001` pour tous les modules : stockage UTC, affichage Montréal, HAE/HNE automatique, aucun décalage fixe codé en dur.
- Aligne Stats AWM 1.5.1 sur cette horloge pour les contacts Hub Client, événements, temps réel, périodes et séries quotidiennes.
- Aucun changement aux Connectors, `site_id`, `instance_uuid`, secrets ou permissions.

## 4.5.172 — 2026-09-09
- Formalise le contrat inter-modules de présence temps réel Stats/Health.
- Ajoute `AWM-STATS-005` : heartbeat éphémère site-scoped, aucune IP ni GPS, GeoIP approximatif seulement.
- Conserve sans changement le registre Connector runtime et l'API `client/stats/collect`; le nouvel événement `presence` utilise le même canal authentifié.

## 4.5.171 — 2026-09-09

- Ajoute `AWM_Core_Site_Connectors::connected_statuses()` comme source canonique des installations Hub Client runtime actives.
- Ajoute `connected_client_ids()` afin que Stats/Health puissent construire leur annuaire depuis les Connectors et non depuis la liste CRM.
- Core → Mises à jour réutilise cette même source pour éviter des définitions divergentes de « site connecté ».
- Ajoute la règle Mémoire AWM `AWM-STATS-004` : KPI actifs = `client_id` attitré + `site_id` runtime autorisés; historique déconnecté conservé séparément.
- Aucun secret Connector, `site_id`, `instance_uuid` ni historique n’est régénéré.

## 4.5.170 — 2026-09-09

- Étend l'API client Stats AWM à `site_id` pour les vues multi-sites distantes.
- Ajoute la période 365 jours à l'API Stats.
- Aligne la description du module Stats sur le cockpit Web multi-sites / santé de collecte de Stats AWM 1.4.0.
- Aucun changement aux secrets Connector, `instance_uuid`, permissions ou déploiements distants.

## 4.5.169 — 2026-09-09

- **Mises à jour → Sites connectés** n affiche désormais que les sites Hub Client dont le Connector runtime est réellement appairé; les sites simplement inscrits dans CRM ou avec une clé en attente sont exclus des cibles de déploiement.
- Ajoute un filtre **Tous les sites / Sites principaux / Sites secondaires** en plus de la recherche et du filtre de statut.
- Conserve toutes les opérations distantes sous le contrat `client_id + site_id + instance_uuid`.
- Ajoute la règle Mémoire AWM `AWM-UPDATES-002` afin de maintenir la séparation entre inventaire CRM et cibles de déploiement réellement connectées.

## 4.5.168 — 2026-09-09

- Réparation canonique des seules révisions seed `v1` créées par Core (`author_id=0`) lorsqu une empreinte invalide persiste.
- La réparation ne dépend plus du SHA historique ni d une comparaison partielle des champs corrompus : les champs couverts par l empreinte sont restaurés depuis le seed officiel AWM.
- Les statuts, dates, lifecycle, révisions `v2+`, règles utilisateur et archives ne sont jamais réécrits.
- `health()` relance la réparation sûre avant de calculer les anomalies, afin que l ordre de chargement admin ne puisse plus laisser 50 faux positifs visibles.
- Ajoute un état de migration visible dans **Core → Mémoire AWM** : version DB, version seed, heure UTC, révisions réparées et anomalies restantes.
- Le bouton admin devient **Restaurer les seeds système officiels** et décrit précisément son périmètre.
- Conserve le chemin de récupération anti-brick pour l import d un Core strictement supérieur.
- Prévoit un plugin de récupération temporaire autonome pour réparer le seed sans dépendre du runtime Core chargé.

## 4.5.166 — 2026-09-09

- Corrige la migration Mémoire AWM 4.5.165 qui pouvait ne reconnaître aucun seed historique malgré 50 empreintes invalides.
- La réparation s appuie désormais sur le **SHA-256 canonique original du seed** comme preuve de provenance, au lieu de dépendre de la valeur `change_reason` déjà corrompue.
- Une révision n est reconstruite automatiquement que si elle est `v1`, créée par le système (`author_id=0`) et que son `content_hash` correspond exactement au seed officiel livré avec Core.
- Les champs couverts par l empreinte sont alors restaurés depuis `development-memory-seed.json`; les statuts, dates et historiques de cycle de vie restent intacts.
- La migration n est marquée terminée que lorsque le contrôle d intégrité retourne réellement **0 anomalie**.
- Le préflight de publication relance la réparation sûre avant de bloquer, afin d éviter un problème de timing au chargement.
- Ajoute dans **Core → Mémoire AWM → Santé** un bouton administratif `Réparer les seeds système reconnus` disponible lorsqu une empreinte invalide subsiste.
- Passe le schéma logique Mémoire AWM à **1.2**.

## 4.5.165 — 2026-09-09

- Corrige un défaut de format dans l insertion SQL des révisions **Mémoire AWM** : `change_reason` était envoyé avec `%d` au lieu de `%s`.
- Ce défaut convertissait les raisons textuelles des 50 règles initiales en `0` après calcul du SHA-256, ce qui faisait apparaître les 50 entrées comme corrompues et bloquait toute publication.
- Passe le schéma logique Mémoire AWM à **1.1** et répare automatiquement uniquement les révisions seed v1 reconnues : auteur système, contenu identique au seed et raison héritée vide/`0`.
- Restaure la raison originale depuis `development-memory-seed.json`, recalcule l empreinte canonique et journalise la migration sans modifier les règles métier.
- Les empreintes inconnues ou réellement altérées restent critiques et continuent de bloquer la publication.
- Corrige définitivement la liste de formats de `$wpdb->insert()` pour toutes les futures révisions.

## 4.5.164 — 2026-09-09
- Corrige la vue **Sites clients** qui restait indexée uniquement par `client_id` et ne pouvait afficher qu'une seule ligne par client.
- La liste des déploiements distants est désormais construite à partir de tous les sites CRM canoniques et de leurs Connectors : site principal et sites secondaires apparaissent séparément avec leur propre `site_id`, URL, état de liaison et inventaire.
- Les inventaires, rafraîchissements, déploiements, vérifications post-installation et rollbacks sont maintenant isolés par `client_id + site_id`.
- Les liens de téléchargement temporaires et leurs signatures HMAC sont liés au `site_id` et au secret de scan du site précis; un site secondaire n'emprunte plus le canal du site principal.
- Les offres de mise à jour retournées par l'API Connector deviennent site-scoped aussi pour les sites secondaires, tout en conservant les métadonnées historiques du site principal pour compatibilité.
- Un site secondaire connu dans CRM apparaît dans **Mises à jour** même avant appairage complet; l'interface distingue `À connecter`, `Code prêt` et le site réellement synchronisé.
- Ajoute une règle Mémoire AWM critique : toute action distante et tout inventaire doivent conserver la granularité `client_id + site_id`; aucune vue de déploiement ne doit écraser les sites d'un même client.

## 4.5.163 — 2026-09-09
- Corrige le parseur des imports directs quand Chrome/Windows renomme un doublon `module-X.Y.Z (1).zip` et que WordPress le normalise en `module-X.Y.Z-1.zip`.
- Un suffixe numérique final est désormais traité comme suffixe de copie, pas comme préversion du module.
- Les préversions explicites commençant par une lettre (`-beta.1`, `-rc.2`) restent supportées.
- La validation reste stricte : nom canonique, version interne du plugin, structure ZIP, documentation, SHA-256 et dépôt doivent rester cohérents.

## 4.5.162 — 2026-09-09
- Ajoute **Mémoire AWM**, un mini-Git interne persistant dans Core pour conserver les règles, faits et décisions de développement entre les conversations.
- Chaque règle possède un identifiant stable, une version, un parent, un type, une catégorie, une priorité, les modules impactés, une source, une raison de changement, un auteur, un horodatage UTC et une empreinte SHA-256.
- Une règle active n est jamais modifiée en place : toute évolution crée une nouvelle révision; l ancienne devient `superseded` ou `archived` et reste consultable.
- La restauration d une ancienne règle crée une nouvelle version au lieu de réécrire l historique.
- Ajoute détection de conflits optimiste : une conversation basée sur une ancienne version ne peut pas écraser une règle plus récente.
- Ajoute contrôle local des secrets : clés privées, tokens Authorization, clés API et valeurs ressemblant à des mots de passe/secrets sont refusés avant stockage.
- Importe 50 règles AWM consolidées pertinentes : publication, développement parallèle, impact inter-modules, multi-sites, Connectors, Studio, Stats/Health, CRM, UX et sécurité; aucune mémoire personnelle n est copiée.
- Ajoute un bloc **Mémoire AWM** dans le tableau de bord Core et un écran administrateur complet avec recherche, filtres, historique, diff entre révisions, archivage, restauration, export JSON, santé et snapshots.
- Avant chaque publication de Suite, Core exécute un préflight de mémoire et bloque uniquement sur une anomalie d intégrité critique; après publication, un snapshot signé des règles actives est créé automatiquement.
- La mémoire peut être consultée par les modules via une API PHP contextuelle afin de charger seulement les règles pertinentes et éviter des tokens inutiles.

## 4.5.161 — 2026-09-09
- Ajoute un stockage de secours **site-scoped** pour les Connectors secondaires lorsqu'une base historique refuse encore l'INSERT SQL après réparation et reconstruction canonique.
- Passe le registre logique Connector en **DB_VERSION 1.6** sans modifier les `site_id`, `instance_uuid` ou secrets existants.
- Le fallback utilise les métadonnées du client pour le record complet et deux index non-autoloadés dérivés des hashes de pairing/runtime afin de conserver une résolution O(1) côté API sans scanner les utilisateurs.
- `status`, `generate`, `find_pairing`, `find_secret`, `complete_pair`, `touch`, `revoke`, `revoke_all`, `update_site_data` et `raw_row` utilisent désormais la même abstraction SQL/meta : Stats, Health, Tech et Hub Client voient le Connector de la même façon quel que soit son backend de stockage.
- Le Connector principal continue d'utiliser son registre existant; le fallback est activé uniquement lorsque la création SQL du site concerné échoue réellement.
- Journalise `connector_site_storage_fallback` sans exposer les codes, secrets, requêtes SQL ou contenus de formulaires.
- Validation terrain prioritaire : générer la clé de `www.demenagementhull.com`, appairer Hub Client, puis confirmer la remontée Stats/Health sous son `site_id` distinct.

## 4.5.160 — 2026-09-09
- Renforce le correctif terrain du registre Connector après confirmation qu'une réparation d'index seule ne suffit pas sur certaines bases historiques.
- Passe `awm_site_connectors` en **DB_VERSION 1.5**.
- Après échec de l'insertion et de la réparation légère, reconstruit automatiquement le registre dans un **schéma canonique neuf**, puis recopie uniquement les colonnes actuelles.
- Préserve les `client_id`, `site_id`, hashes de pairing/runtime, `instance_uuid`, URL appairées, inventaires, profils Tech, utilisateurs synchronisés et horodatages existants; aucun secret n'est régénéré.
- Élimine ainsi les colonnes historiques obligatoires, anciennes clés primaires, contraintes ou index qu'un `dbDelta()` ne peut pas supprimer proprement.
- La bascule ancien registre → registre canonique utilise un renommage atomique; l'ancien registre n'est supprimé qu'après validation de la nouvelle table.
- Étend le diagnostic sûr avec la dérive de schéma (colonnes manquantes, colonnes historiques obligatoires, PK et index uniques) sans journaliser les valeurs Connector.
- Si la reconstruction canonique échoue encore, Core conserve l'ancien registre et journalise la catégorie de l'erreur sans exposer la requête SQL.

## 4.5.159 — 2026-09-09
- Corrige l’échec **« Impossible de créer le Connector de ce site »** observé lors de la génération d’une clé pour un site secondaire.
- Passe le registre `awm_site_connectors` en **DB_VERSION 1.4** et réconcilie automatiquement les schémas historiques avant toute nouvelle insertion.
- Supprime uniquement les anciens index `UNIQUE` qui ne font plus partie du contrat multi-sites; le seul index unique métier conservé est désormais `client_id + site_id`.
- Recrée les index de recherche non uniques attendus et répare `id AUTO_INCREMENT` si une ancienne migration l’a laissé incomplet.
- En cas d’échec d’insertion, Core tente une seule réparation automatique puis réessaie la création sans régénérer, révoquer ou modifier les Connectors existants.
- Journalise la réparation du schéma et, si le second essai échoue, conserve une classification sûre de l’erreur, le nom d’index concerné lorsqu’il est détectable et des empreintes SHA-256, sans journaliser la requête SQL ni les valeurs.
- Aucun changement aux `site_id`, `instance_uuid`, secrets Connector, données Stats/Health ou rattachements CRM existants.

## 4.5.158 — 2026-09-08

- Ajoute la route Connector authentifiée `client/stats/collect`.
- Vérifie le Connector par `client_id`, `site_id`, domaine et `instance_uuid` avant toute ingestion Stats.
- Délègue le stockage métier à Stats AWM; Core reste propriétaire de l'authentification et du transport.
- Ajoute `stats_collect` à la liste blanche des ponts Connector de secours REST/body/admin-ajax/front.
- Aucun secret Connector n'est exposé au navigateur.
- Les sites Hub Client restent identifiés par `client_id + site_id + instance_uuid`; Stats/Health peut donc les agréger au client sans perdre la source exacte.

## 4.5.157 — 2026-09-07

- Corrige une rétrogradation silencieuse de la composition active : les bootstraps historiques Studio 1.14.0 et Tech 1.6.8 pouvaient réécrire la version effective après un import direct supérieur.
- Les fonctions d amorçage Studio et Tech deviennent strictement anti-rétrogradation : une version active égale ou supérieure est toujours conservée.
- Ajoute une réconciliation idempotente dépôt → publication active à chaque chargement admin; seules les versions strictement supérieures sont promues.
- La réconciliation réutilise la promotion sécurisée existante : paquet chiffré Vault, SHA-256, `roadmap_sync`, `composition_revisions` et journal de sécurité.
- Répare automatiquement un Studio 1.16.0 ou un Tech 1.6.9 déjà présent dans le dépôt sans exiger un nouvel upload.
- Aucun changement aux Connectors, `site_id`, `instance_uuid`, secrets ou au multi-sites.

## 4.5.156 — 2026-09-07

- Corrige l ambiguïté de l import rapide dans Core → Mises à jour : la zone de la publication active accepte maintenant autant une Suite qu un module AWM.
- Détecte automatiquement `suite-awm-modulaire-X.Y.Z.zip` ou un nom canonique de module comme `studio-awm-X.Y.Z.zip`, puis délègue au validateur spécialisé existant.
- Un module importé par la zone rapide conserve toutes les protections du dépôt 4.5.154 : documentation obligatoire, structure ZIP, version, SHA-256, Vault, refus d un build différent sous le même numéro et aucune rétrogradation.
- La promotion vers la publication active reste automatique pour une version de module supérieure.
- Les formulaires dédiés « Importer un module » et « Publier une Suite » restent disponibles dans Publication, notes et historique.
- Aucun changement aux Connectors, `site_id`, `instance_uuid`, secrets, permissions ou au multi-sites.

## 4.5.155 — 2026-09-06

- Ajoute des snapshots publics sécurisés `Contexte développement`, `CHANGELOG`, `README` et `ROADMAP` pour chaque module effectivement publié.
- Les documents sont lus depuis les paquets de publication privés/chiffrés; aucun chemin de stockage interne n est exposé.
- Masque automatiquement les lignes susceptibles de contenir secrets Connector, tokens, clés API, mots de passe, clés privées ou entêtes Authorization.
- Journalise la publication des snapshots documentaires avec la composition effective de la Suite.

# 4.5.154 — dépôt central de modules et résolution anti-rétrogradation

- Ajoute `awm_core_module_repository` avec plusieurs versions conservées par module.
- Ajoute l import direct d un module depuis Core → Mises à jour, avec identification du module, version sémantique, structure ZIP, SHA-256 et chiffrement Vault.
- Exige `README.md`, `CHANGELOG.md` et `ROADMAP.md` pour tout nouvel import direct; les anciens paquets d une Suite restent tolérés comme héritage pour éviter une migration destructive.
- Un module direct supérieur peut être promu immédiatement comme version effective de la publication active.
- Une nouvelle Suite vérifie encore la cohérence de ses paquets sources avec son manifeste/roadmap, puis résout chaque module contre le dépôt et la publication active.
- Une version supérieure existante n est plus une erreur : elle est conservée et injectée dans `roadmap_sync.versions` et `module_updates`.
- Interdit les builds différents sous le même numéro de version : une correction de build exige une version supérieure.
- Journalise import, promotion, résolution, publication et erreurs de validation.
- Conserve `composition_revisions` pour l audit des changements de modules effectués sans reconstruire toute la Suite.
- Aucun changement aux Connectors, secrets, `site_id`, `instance_uuid` ou à la télémétrie multi-sites.

# 4.5.153 — correction globale de l heure Alliance
- Ajoute une horloge Core canonique `America/Toronto` avec gestion automatique HNE/HAE, indépendante du fuseau général WordPress.
- Les nouvelles publications sont stockées explicitement en UTC et converties uniquement à l affichage.
- Corrige immédiatement l historique des publications existantes en reconstruisant leur instant UTC depuis l identifiant de release `Suite-gmdate`, ce qui retire le décalage de quatre heures sans modifier la base.
- Corrige aussi l affichage du journal de sécurité et des heures du moniteur de tâches Core.
- Publie Tech AWM 1.6.8 afin que les dates Tech centrales utilisent la même horloge Alliance.
- Ne modifie aucun Connector, `site_id`, secret, télémétrie ou permission multi-sites.

# 4.5.152 — monitoring Tech multi-sites par site_id
- Publie Tech AWM 1.6.7.
- Passe `awm_site_connectors` en DB_VERSION 1.3 avec profil Tech et date de synchronisation propres à chaque site.
- Étend le canal serveur-à-serveur Core afin que Tech puisse interroger le `site_id` exact avec le secret de scan de cette installation.
- Conserve intégralement la restauration des anciens Connectors validée en Suite 4.5.151.
- Les déploiements automatiques historiques restent volontairement centrés sur le principal; aucun secondaire ne peut déclencher une mise à jour sur le mauvais site.

# 4.5.151 — cohérence stricte ZIP / manifeste / roadmap
- Corrige le rejet de publication de Suite 4.5.150 : le ZIP Core annonçait 4.5.150 alors que `roadmap_sync.versions.core` et `roadmap_sync.versions.suite` étaient restés à 4.5.149.
- Aligne Core AWM 4.5.151 dans l’en-tête du plugin, la constante runtime, le registre public de versions, `manifest.json` et la synchronisation roadmap.
- Conserve intégralement la restauration automatique des Connectors historiques introduite en 4.5.150 et le schéma Connector DB_VERSION 1.2.
- Aucun Connector n’est régénéré ou révoqué par cette correction de publication.

# 4.5.150 — restauration automatique des Connectors existants
- Corrige la régression où la vue Mises à jour pouvait afficher `Sites clients (0)` après la migration multi-sites alors que les Connectors 4.5.147 existaient toujours.
- Réimporte automatiquement le hash Connector historique du site principal dans le registre `awm_site_connectors`, sans générer de nouvelle clé et sans demander de reconnexion aux sites.
- Ajoute un repli de lecture sur les métadonnées Connector historiques si le registre multi-sites est temporairement indisponible ou incomplet.
- Récupère aussi l URL de jumelage historique lorsque l URL principale CRM manque pendant la migration.
- Une ligne de migration marquée `revoked_at` par erreur est réactivée uniquement si le secret historique intact existe encore; une révocation explicite reste donc respectée.
- Le runtime peut auto-récupérer un Connector pré-4.5.148 à partir de son hash historique avant d appliquer les contrôles `site_id` / `instance_uuid`.
- Passe le schéma Connector à DB_VERSION 1.2.

# 4.5.149 — correctif registre Connector et publication
- Publie Core AWM 4.5.149; les autres modules restent inchangés.
- Corrige les warnings `Trying to access array offset on null` du registre Connector multi-sites lors de la migration du site principal.
- Force une réconciliation du schéma `awm_site_connectors` avec DB_VERSION 1.1 et refuse proprement un enregistrement introuvable au lieu de lire un tableau nul.
- Conserve la règle de publication strictement croissante : une Suite 4.5.148 déjà publiée doit être suivie par 4.5.149 ou supérieur.
- Aucun Connector existant n’est révoqué par ce correctif.

# 4.5.147 — fiche client multi-sites premium
- Publie CRM AWM 1.6.19; Tech AWM reste 1.6.6.
- Refonte responsive du bloc Sites du client avec cartes premium et hiérarchie Site principal / Sites secondaires.
- Ajoute `site_type` distinct de l'environnement technique et 16 types de sites, dont Landing page, Sous-domaine, Répertoire, Boutique, Blog, Portail client, Campagne et Microsite.
- Remplace le contrôle radio de promotion par une action directe **Promouvoir** avec confirmation visuelle avant enregistrement.
- Conserve le site principal comme source de vérité des couleurs, typographies et règles de marque.

# 4.5.146 — architecture client multi-sites
- Publie CRM AWM 1.6.18 et Tech AWM 1.6.6.
- Ajoute Site principal + Sites secondaires dans la fiche client canonique.
- Conserve le site principal comme source graphique officielle.
- Ajoute `site_id` persistant par site et prépare l association runtime/site.
- Tech affiche les sites secondaires non connectés sans leur attribuer la télémétrie du site principal.
- Aligne le bootstrap Core sur Tech 1.6.6.

# 4.5.145 — monitoring Tech proactif et inventaires à la demande
- Publie Tech AWM 1.6.5 et Hub Client AWM 1.11.32.
- Ajoute un scan central horaire qui réévalue les vulnérabilités correspondant réellement aux versions installées et journalise les nouvelles correspondances critiques.
- Ajoute l actualisation manuelle des inventaires depuis le dashboard et la vue Mises à jour via une route Hub Client privée authentifiée.
- Affiche le dernier scan automatique dans Tech AWM et conserve la politique sans API de vulnérabilités payante.
- Aligne le bootstrap Core sur Tech 1.6.5.

# 4.5.144 — correctif de publication Suite

- Publie une version de Suite strictement supérieure à la publication active 4.5.143.
- Conserve Tech AWM 1.6.4 et les autres modules inchangés; aucun rollback fonctionnel.
- Aligne le registre de versions Core et la roadmap sur Suite 4.5.144.
- Évite de présenter un paquet 4.5.143 comme nouvelle publication lorsqu'il est déjà actif.

# 4.5.143 — inventaire logiciel et journal sécurité Tech
- Publie Tech AWM 1.6.4 et aligne le paquet bootstrap Core sur la même version.
- Ajoute l inventaire central des versions WordPress, extensions et thèmes avec les mises à jour proposées par WordPress.
- Compare les modules Suite AWM installés sur Alliance avec la publication active afin de repérer immédiatement les versions en retard.
- Ajoute un journal de vulnérabilités fondé uniquement sur Wordfence Intelligence V3, accessible gratuitement avec une clé gratuite Wordfence; aucune API de vulnérabilités payante n est requise.
- La clé reste chiffrée dans le coffre Core côté Alliance et n est jamais envoyée aux sites clients.
- Les alertes ne sont créées qu après correspondance entre la version réellement installée et les plages de versions affectées publiées par Wordfence.
- Corrige le décalage du bootstrap précédent où Core ciblait Tech 1.6.3 sans embarquer le ZIP correspondant.

# 4.5.142 — apparence avancée de la fenêtre Tech
- Publie Tech AWM 1.6.3.
- Sépare l opacité des fonds de l opacité du texte et des bordures.
- Ajoute un choix de police en direct sans ressource externe.
- Conserve couleur d accent, presets Matrix / Bleu premium, session persistante, Elementor et moteur d actions frontend.

# 4.5.141 — contenu et images Tech AWM
- Publie Tech AWM 1.6.2 et Hub Client AWM 1.11.31.
- Corrige les demandes de couleur de titre avec normalisation des couleurs nommées et repli CSS frontend réversible lorsqu aucun ID Elementor fiable n est disponible.
- Ajoute les demandes de réécriture de contenu : rallonger, condenser, corriger et rendre plus formel/professionnel.
- Ajoute la génération d image centralisée Alliance, import WordPress et remplacement contrôlé d un widget image Elementor sélectionné.
- Conserve les permissions Alliance, la journalisation, les snapshots, le contrôle de concurrence et le rollback.

# 4.5.140 — actions frontend Tech
- Publie Tech AWM 1.6.1 et Hub Client 1.11.30.
- Tech privilégie maintenant les actions exécutables plutôt que les instructions manuelles pour les demandes compatibles.
- Ajoute les styles Elementor sécurisés : couleurs, fonds, alignement, typographie responsive, marges et padding.
- Conserve validation Alliance, snapshot, contrôle de concurrence, rollback et journalisation.

# 4.5.139 — Tech AWM 1.6.0 / frontend + dashboard monitoring

- Publie Tech AWM 1.6.0.
- Fait du frontend la surface d intervention principale avec fenêtre Tech privee persistante; Elementor devient le mode avance.
- Ajoute un dashboard principal source-first : KPI, priorites, score de sante derive, sites surveilles et activite recente.
- Les blocs du dashboard ouvrent leur source dans des popups et la navigation principale reste dans le menu WordPress a gauche.
- Ajoute Monitoring, Alertes, Mises a jour, Sauvegardes, Securite, Rapports, Journal et Reglages sans simuler les sondes encore absentes.
- Aligne le bootstrap Core sur Tech AWM 1.6.0.

# 4.5.138 — session Tech persistante WordPress ↔ Elementor

- Publie Tech AWM 1.5.18.
- Conserve la boîte d intervention pendant la navigation dans wp-admin et Elementor.
- Ajoute les préférences locales de couleur terminale et d opacité totale.
- Aligne le paquet bootstrap Tech sur 1.5.18.
- Roadmap : ajoute la reprise multi-pages contrôlée et la barre de session globale dans Futur.

# 4.5.137 — isolation du preview Elementor

- Publie Tech AWM 1.5.17.
- Corrige la cause identifiée du blocage Elementor **Loading / Enable Safe Mode** : le cookie de session Tech était interprété dans l iframe `elementor-preview`, qui pouvait être redirigée vers `wp-admin`.
- Le preview Elementor est maintenant exclu avant toute validation, redirection ou handoff Tech.
- Une session cookie seule ne déclenche plus le bootstrap front-end; un lancement Tech explicite est requis.
- Conserve le handoff direct Alliance → Elementor et la boîte terminal Matrix.
- Roadmap : validation terrain du preview isolé maintenant; gate E2E preview-ready au Futur.

# 4.5.136 — Safe Boot Elementor et terminal Matrix

- Publie Tech AWM 1.5.16.
- Retarde le montage de la boîte Tech jusqu à l initialisation réelle d Elementor afin de ne pas perturber le boot de l éditeur.
- Supprime le MutationObserver global pendant le chargement et empêche le double enqueue/localize des assets Tech.
- Nettoie le thème terminal Matrix premium : console monospace, vert lumineux et fond noir/vert.
- Roadmap : Maintenant = validation terrain sans Safe Mode; Futur = gate E2E qui bloque une publication si Elementor reste sur Loading/Safe Mode.

# 4.5.135 — handoff Elementor indépendant du runtime chargé

- Publie Hub Client 1.11.29 et Tech AWM 1.5.15.
- Le préflight Tech relit désormais `update/status` avant toute tentative de déploiement afin d éviter les faux états causés par une télémétrie périmée.
- Hub Client peut préparer directement le handoff Elementor après validation Connector de la session Alliance, même si une ancienne classe Tech reste chargée dans la requête courante.
- Core conserve la preuve de version runtime et la route privée prête avant de considérer Tech disponible.
- Roadmap : ajoute en Futur un test E2E obligatoire du parcours création session → handoff → wp-admin Elementor → boîte Tech → rollback.

# 4.5.132 — récupération automatique d un Tech bloqué

- Publie Hub Client AWM 1.11.28.
- Lorsqu un déploiement Tech échoue ou reste sur une ancienne version après vérification, Core lance automatiquement **une seule** réparation propre au lieu de laisser le site en erreur.
- La récupération conserve une sauvegarde, demande le remplacement canonique de Tech, puis relit le site jusqu à confirmer le runtime cible et la route privée Elementor.
- Les autres sites continuent leurs mises à jour même si la récupération d un site échoue.
- Roadmap : ajoute en Futur un préflight distant des permissions, fichiers verrouillés et état OPcache avant installation.

# 4.5.131 — correction structurelle du paquet Hub Client

- Corrige la Suite précédente où `hub-client-awm-1.11.26.zip` contenait deux dossiers racine (`hc/` et `hub-client-awm/`).
- Publie Hub Client 1.11.27 dans un ZIP contenant **uniquement** `hub-client-awm/` à sa racine, conformément au validateur Core.
- Ajoute cette erreur de packaging au préflight de livraison afin de la détecter avant import.
- Conserve Tech AWM 1.5.12 : le prochain test fonctionnel reprend directement l ouverture de la boîte Tech dans Elementor.
- Roadmap : ajoute la validation des racines ZIP en Prochaines étapes et un build reproductible sans artefacts temporaires au Futur.

# 4.5.130 — suppression du 404 de preparation Elementor

- Publie Hub Client 1.11.26 et Tech AWM 1.5.12.
- Core ne considere plus Tech comme pret sur la seule version runtime : `update/status` doit aussi confirmer `tech_prepare_route_ready`.
- Le point d entree prive de preparation Elementor est possede par Hub Client afin qu une mise a jour Tech ne puisse plus produire `No route was found matching the URL and request method`.
- Conserve la verification post-installation dans une nouvelle requete PHP et le bootstrap Tech autonome.
- Ajoute au Futur un test de contrat automatique des routes privees avant publication.

# 4.5.129 — handoff Elementor serveur et preuve runtime

- Publie Tech AWM 1.5.11 et Hub Client AWM 1.11.25.
- L ouverture Elementor ne transite plus par la page publique : Core prépare directement un handoff privé sur le site client puis redirige vers `wp-admin`.
- Le handoff local est temporaire, à usage unique et lié au `post_id` résolu par le site client.
- Core vérifie désormais `tech_runtime_version` réellement chargé en PHP après une mise à jour distante, et non seulement l en-tête de version du fichier.
- Hub Client invalide OPcache et désactive les anciens runtimes Tech concurrents après mise à jour.
- Ajoute au Futur un test E2E de lancement Elementor et un préflight runtime obligatoire avant publication.

# 4.5.128 — continuité Tech vers Elementor

- Publie Tech AWM 1.5.10.
- Corrige la perte possible de session entre le front client et `wp-admin`, notamment lorsque le site passe de `www` au domaine nu.
- Ajoute un handoff serveur temporaire et un cookie de domaine sécurisé pour restaurer la session Elementor.
- Injecte directement les assets de la boîte Tech dans `admin_head` pendant une intervention valide.
- Ajoute un diagnostic visible si Elementor reçoit une intervention mais ne peut pas récupérer sa session.
- Roadmap : ajoute télémétrie de démarrage en Prochaine étape et test E2E www/domaine nu au Futur.

# 4.5.127 — cohérence stricte Suite / manifeste / roadmap

- Corrige la publication 4.5.126 dont `roadmap_sync.versions` était resté sur 4.5.125 malgré un ZIP Core 4.5.126.
- Aligne automatiquement les versions de publication avec les versions réelles des 10 paquets lors de la construction de la Suite.
- Conserve le contrôle strict à l import : ZIP, manifeste et synchronisation roadmap doivent rester identiques.
- Roadmap : ajoute un contrôle de cohérence de publication et prévoit un préflight automatisé avant chaque livraison.

# 4.5.126 — boîte Tech fiable dans Elementor
- Publie Tech AWM 1.5.9.
- Aligne le bootstrap Core sur Tech 1.5.9.
- La boîte d intervention utilise désormais les hooks natifs de l éditeur Elementor, avec fallback JavaScript et anti-doublon.
- Roadmap : ajoute validation terrain immédiate, test de fumée Elementor et scénario E2E navigateur futur.

# 4.5.125 — intervention Elementor sans blocage de version

- Publie Tech AWM 1.5.8.
- Le runtime Tech distant requis pour une intervention Elementor est maintenant préparé automatiquement depuis la publication active.
- Core déploie ou met à jour Tech sur le site client, relit l inventaire puis confirme la version avant la création de session.
- Le bootstrap Core est aligné sur Tech AWM 1.5.8 afin qu une nouvelle installation Alliance ne réintroduise pas une version plus ancienne.
- La roadmap ajoute la validation terrain de ce parcours et la préparation anticipée des runtimes Tech en Futur.

# 4.5.124 — Horodatage Tech localisé
- Publie Tech AWM 1.5.7.
- Aligne le paquet bootstrap Tech de Core sur 1.5.7 afin qu une installation Alliance neuve ne retombe plus sur un runtime historique.
- Corrige le décalage UTC du dernier contact affiché dans Tech AWM → Sites.
- Les événements Tech restent stockés en UTC et sont convertis au fuseau WordPress Alliance à l affichage.
- Ajoute au Futur une chronologie multi-fuseaux unifiée pour la maintenance et la sécurité.

# 4.5.123 — Stabilisation Tech Elementor et roadmap orientée livraison
- Publie Tech AWM 1.5.6.
- Ajoute un préflight de disponibilité avant l ouverture Elementor pour éviter les sessions qui s ouvrent sur un runtime client trop ancien ou sans télémétrie Elementor confirmée.
- Affiche l état et le temps restant de la session dans l unique boîte Tech.
- Attend automatiquement l iframe Elementor, gère son rechargement et durcit les contrôles JavaScript pour limiter les erreurs bloquantes.
- Après Appliquer ou Rollback, rafraîchit l aperçu plutôt que toute l interface lorsque l API Elementor est disponible.
- Corrige le registre de versions roadmap qui affichait encore Tech 1.5.3.
- Ajoute explicitement Maintenant, Prochaines étapes et Futur pour Tech; l examen du Futur devient une étape permanente de chaque livraison.

# 4.5.122 — Import de Suite tolérant aux noms de téléchargement
- Corrige le refus des fichiers valides renommés automatiquement par le navigateur ou Windows, par exemple `suite-awm-modulaire-4.5.122(1).zip`.
- Core accepte maintenant les suffixes `-1`, `(1)`, `(2)` et variantes avec espace, tout en exigeant strictement le préfixe `suite-awm-modulaire-` et une version X.Y.Z.
- La version publiée continue d'être extraite du nom canonique et doit rester strictement supérieure à la dernière publication.

# 4.5.121 — Tech AWM 1.5.5 / intervention Elementor directe
- Publie Tech AWM 1.5.5.
- Les interventions Tech ouvrent directement Elementor sur la page ciblée.
- Une seule boîte de dialogue Tech privée est affichée dans Elementor; aucune palette n est rendue sur le front-end public.
- Conserve session temporaire, inspection, application contrôlée, diagnostic et rollback.

# 4.5.120 — Tech AWM 1.5.4 / liste d’intervention directement visible
- Publie Tech AWM 1.5.4.
- La Vue d’ensemble Tech affiche maintenant la liste des sites Hub Client directement au lieu d’un simple lien « Ouvrir la liste d’intervention ».
- Conserve l’onglet Sites dédié, la recherche et les actions Intervenir / Fiche Tech / Voir.
- Corrige le doublon du champ de recherche de la vue Sites.

# 4.5.119 — Tech AWM 1.5.3 / palette dans l’éditeur Elementor
- Publie Tech AWM 1.5.3.
- Corrige la continuité d’une session d’intervention Alliance lorsque la page cible est ouverte avec **Modifier avec Elementor** dans `wp-admin`.
- La palette Tech privée est maintenant injectée directement au-dessus de l’éditeur Elementor et s’ouvre automatiquement pendant la session valide.
- Le mode Inspecter cible l’iframe de prévisualisation Elementor afin de sélectionner directement les éléments de la page.
- Supprime le doublon de palette dans l’iframe Elementor et conserve une seule boîte de dialogue de travail.
- Sans session Alliance valide, aucun composant Tech n’est visible dans Elementor, Hub Client ou le front-end public.

# 4.5.118 — Tech AWM 1.5.2 / onglet Sites réellement visible
- Corrige le shell administratif Core qui affichait encore **Clients** vers CRM au lieu de la nouvelle vue **Sites** de Tech AWM.
- Ajoute l’onglet visible **Sites** directement après Vue d’ensemble dans Tech AWM.
- Cliquer sur Tech AWM ouvre désormais la liste des sites Hub Client par défaut.
- Publie Tech AWM 1.5.2 et conserve Hub Client invisible à Tech côté client.
- La liste Sites reste alimentée par CRM canonique + inventaire Core, sans répertoire parallèle.

# 4.5.117 — Tech AWM 1.5.1 / liste Hub Client d’intervention
- Publie Tech AWM 1.5.1.
- Tech AWM affiche automatiquement tous les sites où Hub Client est confirmé installé par l’inventaire Core.
- La liste réutilise le client_id CRM canonique et ne crée aucun doublon de fiche client.
- Chaque ligne expose Hub Client, Tech AWM, santé, mises à jour, alertes, transport Connector et dernier contact.
- Alliance peut lancer une intervention directement depuis la liste lorsque Tech est installé et autorisé, ou ouvrir la fiche Tech complète.
- Core embarque le bootstrap Tech AWM 1.5.1 et son SHA-256 exact.

# 4.5.116 — Hub Client 1.11.24 / administration locale épurée

- Publie Hub Client AWM 1.11.24.
- Retire le grand panneau explicatif Sécurité de l’administration locale des sites clients, sans désactiver aucune protection technique.
- Maintient Tech AWM 1.5.0 comme agent privé Alliance, invisible dans le Hub Client et dans ses écrans locaux.
- Conserve les protections Connector, HTTPS, sessions, domaine, déploiement distant et provisioning Tech en arrière-plan.
- Synchronise le registre de versions roadmap sur Core 4.5.116, Hub Client 1.11.24 et Tech AWM 1.5.0.

# 4.5.115 — Tech AWM 1.5.0 privé et intervention distante

- Publie Tech AWM 1.5.0 et Hub Client AWM 1.11.23.
- Tech disparaît complètement du Hub Client; il devient un agent interne Alliance uniquement.
- Ajoute les routes Connector sécurisées de validation et d audit des sessions d intervention front-end.
- Les sessions Tech sont temporaires, liées au client, au domaine et à la page; le jeton brut n est jamais enregistré côté Alliance.
- Tech 1.5.0 ajoute santé, mises à jour, alertes sécurité, inspection Elementor, réparation/design et rollback pendant une session Alliance.
- Core embarque le bootstrap Tech AWM 1.5.0 et son SHA-256 exact.

# 4.5.114 — visibilité complète de la Suite et Tech AWM 1.4.3
- L'écran de confirmation d'installation affiche désormais tous les paquets reconnus, répartis entre À installer, Déjà à jour / sans action locale et À publier sur les sites clients.
- Évite l'impression que seul Core existe lorsqu'il est le seul module dont la version locale change.
- Publie Tech AWM 1.4.3 et Hub Client AWM 1.11.22 avec centre de santé Connector, diagnostics et réparations ciblées.
- Le bootstrap Core embarque désormais Tech AWM 1.4.3 et son SHA-256 exact.

# 4.5.113 — réparation déploiement distant / installation Tech manquante
- Corrige le déploiement distant qui pouvait déclarer Hub Client en échec alors que ses nouveaux fichiers étaient déjà installés : Core relit maintenant le site dans une nouvelle requête avant de conclure.
- Autorise la publication active à proposer **Tech AWM même lorsqu'il est totalement absent** du site, uniquement si Tech est activé dans la fiche CRM canonique du client.
- Confirme après chaque installation distante que la version cible Hub Client ou Tech est réellement présente avant d'afficher le succès.
- Traite Hub Client avant Tech sur chaque site afin que le nouvel agent d'installation soit disponible avant le provisioning Tech.
- Une erreur sur un site ne suspend plus les autres sites après deux échecs; chaque tâche est isolée et le diagnostic expose maintenant le code d'erreur précis.
- Publie Hub Client AWM 1.11.21 avec auto-provision sécurisé du paquet Tech manquant.

# 4.5.112 — Hub Client 1.11.20 / logo canonique dans toutes les sections
- Publie Hub Client AWM 1.11.20 avec un composant de marque unique pour tout le portail client.
- Garantit que le PNG Alliance officiel est servi sans filtre, masque, recoloration, transformation ni redessin dans Accueil, CallTracker, Stats, Tech AWM, Mon compte et leurs sous-sections.
- Conserve le badge Hub orange comme asset séparé.

# 4.5.111 — Hub Client 1.11.19 / intégrité stricte du logo Alliance
- Publie Hub Client AWM 1.11.19 avec contrôle SHA-256 du logo Alliance officiel.
- Le logo canonique est accepté uniquement si son empreinte correspond à `1b0dcbd96e1ed931ce785cda2918e7dc38597c214735e21c92243c02eb43b13a`; toute variante modifiée est refusée à l'affichage.
- Le badge Hub orange reste séparé et superposé dans le menu WordPress, le bandeau et le portail `/hub/`.
- Les autres modules, le Connector, les données CRM et le moteur de déploiement restent inchangés.

# 4.5.110 — Hub Client 1.11.18 / logo Alliance officiel verrouillé
- Publie Hub Client AWM 1.11.18 avec le logo Alliance officiel conservé pixel pour pixel.
- Le badge Hub orange reste un asset séparé dans le menu WordPress, le bandeau d'administration et le portail `/hub/`.
- Retire le SVG composite qui redessinait le logo Alliance afin d'empêcher toute réutilisation d'une variante du logo.
- Conserve le moteur de déploiement, le Connector, les données CRM et les autres modules inchangés.

# 4.5.109 — Hub Client 1.11.16
- Publication de Hub Client 1.11.16 avec logo Hub canonique renommé/versionné.

## 4.5.108 - 2026-09-05

- Publie Hub Client 1.11.15 avec auto-reparation des copies dupliquees et preuve de runtime charge.
- Le deploiement distant peut maintenant basculer vers la copie canonique Hub Client sans demander une nouvelle liaison CRM.
- La roadmap suit la validation du shell Premium une fois le runtime 1.11.15 confirme.

## 4.5.108 - 2026-09-05
- Corrige l inventaire Hub Client sur les installations historiques dont le dossier de plugin n est pas canonique.
- Utilise la version Connector comme preuve de presence Hub Client lorsque l ancien agent renvoie un inventaire incomplet.
- Refuse de marquer un deploiement comme reussi si la version cible n est pas confirmee apres installation.
- Aligne le statut : Hub a verifier ne peut plus afficher A jour.

## 4.5.106 — 2026-09-05

- Publie Hub Client AWM 1.11.13 avec le logo Hub AWM complet et le badge orange Hub.
- Le panneau Hub Client local adopte le style Premium sombre de Hub AWM.
- Aucun changement aux donnees CRM, au Connector ou au moteur de deploiement.

## 4.5.105 — 2026-09-04
- Ajoute un bloc Roadmap AWM Premium dans la zone centrale de Core → Mises à jour.
- Le bouton Ouvrir la roadmap mène directement vers https://alliancewebmarketing.ca/hub/roadmap/ dans un nouvel onglet.
- Le bloc réutilise les variables CSS du shell AWM et le titre de synchronisation de la publication active.
- Le lien comble utilement l’espace entre le titre et les KPI sans alourdir l’interface.

## 4.5.104 — 2026-09-04
- Recompose la zone supérieure de Core → Mises à jour pour supprimer le grand espace vide central : les quatre indicateurs sont maintenant intégrés directement sous le titre, à gauche de la carte Publication active.
- Compacte la grille des sites clients afin que Site, Hub Client, Tech, Statut, Mises à jour et Actions restent rapprochés, sans colonne centrale surdimensionnée.
- Ajoute une action Réparer sur les sites dont l’inventaire Hub Client n’est pas synchronisé; Core retente le Connector, recharge l’inventaire et affiche le diagnostic si la réparation automatique échoue.
- Conserve le CSS Premium clair/sombre, l’import rapide de Suite, Publication & historique et les contrôles de sécurité existants.

## 4.5.103 — 2026-09-04

- Rétablit un import rapide de la Suite directement dans Core → Mises à jour.
- Ajoute une zone compacte « Importer une nouvelle Suite (.zip) » visible dans le bloc Publication active.
- Accepte le glisser-déposer ou la sélection de fichier depuis l’ordinateur.
- Le formulaire réutilise le validateur Core existant : version supérieure, manifeste, 10 paquets, roadmap et SHA-256.
- Le canal rapide publie en Stable et récupère automatiquement les notes incluses dans le ZIP lorsque le champ de notes est vide.
- Conserve le panneau Publication & historique pour les réglages avancés et l’historique.

## 4.5.102 — 2026-09-04

- Corrige le bouton « Publication & historique » de Core → Mises à jour.
- Fusionne les classes CSS/JavaScript du bouton afin que le gestionnaire d’ouverture soit réellement attaché.
- Le bouton ouvre maintenant le panneau « Publication, notes et historique » puis défile jusqu’à celui-ci.
- Ajoute un lien serveur de repli avec `awm_update_panel=publication` afin que le panneau reste accessible même si JavaScript est indisponible.
- Conserve le CSS Premium compact introduit en 4.5.101.

## 4.5.101 — 2026-09-04

- Refonte UX complète de Core → Mises à jour avec une vue compacte adaptée à la ligne de flottaison.
- Les modules hébergés chez Alliance ne sont plus répétés dans chaque carte de site client.
- Les sites clients passent en tableau compact avec recherche, filtre, statut, Hub Client, Tech AWM et actions directes.
- Publication active, métriques, mises à jour Alliance et déploiement distant sont concentrés dans la partie supérieure de l’écran.
- Publication d’une Suite, notes et historique restent accessibles dans un panneau repliable sans alourdir la vue principale.
- Le nouveau rendu respecte les variables CSS du shell AWM et reste responsive en clair/sombre.

## 4.5.100 — 2026-09-04
- Clarifie la carte « Installer sur Alliance » : Hub Client est un paquet client, pas un module local manquant.
- Masque le rollback local Hub Client lorsqu’il n’est pas installé sur Alliance.
- Affiche immédiatement le nombre et le nom des modules Alliance réellement à mettre à jour.
- Met à jour l’inventaire local côté navigateur après chaque installation réussie afin d’éviter les faux écarts sans rechargement.
- Conserve la séparation stricte entre mise à jour Alliance et déploiement distant vers les sites clients.

## 4.5.99 — 2026-09-04
- Corrige le faux blocage « La roadmap doit contenir au moins un avancement » pendant la publication d une Suite.
- Normalise les anciens `roadmap_sync.module_updates` texte en lignes structurées compatibles.
- Exige toujours un avancement réel pour chaque module dont la version augmente.
- Synchronise le registre public sur Core 4.5.99, Hub Client 1.11.12 et Tech AWM 1.4.2.

## 4.5.98 — 2026-09-04
- Corrige le 403 persistant de vérification Tech AWM depuis Hub Client.
- Ajoute un canal Connector de secours admin-ajax limité aux opérations Tech.
[Ligne masquée automatiquement par Core AWM : contenu sensible potentiel]
- Auto-répare l'approbation Core uniquement lorsqu'un secret Connector valide et le domaine jumelé sont confirmés.
- Une révocation explicite reste définitive car elle supprime le secret Connector.

## 4.5.97 — 2026-09-04
- Corrige les déploiements distants Hub Client/Tech qui pouvaient échouer avec `Forbidden` au téléchargement du paquet.
- Les paquets distants sont maintenant servis par un endpoint REST Core dédié avec lien signé temporaire, lié au secret Connector du client et au `client_id` CRM autorisé.
- Le téléchargement ne dépend plus de `admin-post.php`, ce qui évite les refus de certains WAF/hébergements sur les appels serveur-à-serveur.
- Le contrôle d'accès reste strict : client approuvé, canal Connector actif, permission Tech si applicable, expiration, signature HMAC et SHA-256 du paquet.
- Core transmet aussi l'authentification du canal distant dans le corps HTTPS en repli, sans supprimer l'en-tête existant.
- Publie Hub Client AWM 1.11.11 avec authentification distante plus robuste et messages d'erreur de téléchargement explicites.
- Les nouvelles publications stockent les ZIP de modules chiffrés au repos via le coffre Core; les anciennes publications sont migrées progressivement sans laisser de copie en clair après migration.
- Le déchiffrement n existe qu en mémoire/fichier temporaire protégé au moment d une installation ou d un téléchargement autorisé.

## 4.5.96 — 2026-09-04
- Publie CRM AWM 1.6.17 et Hub AWM 4.5.51.
- La fiche client CRM affiche désormais en permanence **Hub Client & connexion** et **Services**.
- Le Connector et l autorisation restent sécurisés par Core; les abonnements restent propriétaires de CRM et leur application reste propriétaire de Hub.
- Aucun doublon client ou service maître n est introduit.

## 4.5.95 — 2026-09-04

- Renforce l'authentification Hub Connector utilisée par Tech AWM.
- Core peut retrouver la fiche CRM jumelée à partir du hash du secret Connector si un ancien `client_id` local est devenu obsolète.
- Le domaine lié reste vérifié avant toute autorisation et la récupération d'identifiant est journalisée.
- Publie Hub Client 1.11.10 et Tech AWM 1.4.1.
- CRM demeure l'unique source canonique des clients; aucune fiche parallèle n'est créée.

## 4.5.94 — 2026-09-04
- Publie Hub AWM 4.5.50 avec la correction des warnings `Cannot modify header information` sur les routes Clients.
- Les redirections vers la fiche client CRM canonique sont déclenchées avant le rendu de l admin WordPress.
- La source unique des clients reste CRM AWM et les modules conservent uniquement leurs données métier liées au même `client_id`.
- La validation terrain CallTracker → Clients et Hub → Clients reste dans Maintenant.

## 4.5.93 — 2026-09-04
- Corrige la navigation Thech AWM : le menu principal ouvre son tableau de bord Premium; CRM reste uniquement la source canonique des clients.
- Publie Tech AWM 1.4.0 avec conversation multi-tour corrigée (`assistant` → `output_text`, utilisateur → `input_text`).
- Ajoute la fenêtre Tech AWM flottante directement sur le front-end des pages WordPress/Elementor autorisées.
- Tech AWM résout maintenant une URL interne fournie depuis Hub Client vers le `post_id` réel et conserve cette page comme cible de `Appliquer` et du rollback.
- Publie Hub Client AWM 1.11.9 avec le logo produit Hub AWM canonique dans le portail et l administration locale.
- Le logo client provenant de CRM ne remplace plus l identité visuelle du produit Hub.
- La validation terrain du chat front-end et du logo reste classée Maintenant dans la roadmap.

## 4.5.92 — 2026-09-04
- Corrige le déploiement distant de Tech AWM autonome : lorsqu il est activé dans la fiche CRM, Core peut désormais l installer même s il est absent du site client.
- Les sites distants affichent explicitement Tech AWM « À installer » ou « Désactivé côté Alliance ».
- Le serveur refuse toute installation distante de Tech AWM si le client ne l a pas activé depuis sa fiche CRM.
- Publie Hub Client 1.11.8 avec visibilité Tech AWM indépendante de la présence préalable du runtime.

## 4.5.91 — 2026-09-04
- Publie Hub Client AWM 1.11.7.
- Hub Client utilise exactement le logo Hub AWM, sans variante ni badge client.
- Hub Client devient explicitement indépendant de CallTracker : aucune campagne n’est requise pour le jumelage, l’administration ou le portail `/hub/`.
- L’absence de campagne devient un état informatif limité aux fonctions CallTracker/Formulaires.
- Les alertes passives de sous-modules ne déclenchent plus le modal d’erreur Premium de l’administration Hub Client.

## 4.5.90 — 2026-09-04
- Harmonise la Suite autour de CRM AWM comme source unique des clients.
- Publie CRM AWM 1.6.16, Hub AWM 4.5.49 et Tech AWM 1.3.0.
- La fiche client CRM devient la vue unifiée avec les onglets des modules reliés au même `client_id`.
- Hub et Tech ne maintiennent plus de fiche client maître parallèle.
- Met à jour le bootstrap Tech et la roadmap centrale.

## 4.5.89 — 2026-09-04
- Publie **Hub Client AWM 1.11.6** avec le correctif de l’erreur critique `AWM_Client_Hub_Form_Capture::render_admin()`.
- Le bloc Réception directe des formulaires accepte maintenant correctement les 2 arguments transmis par `awm_client_hub_admin_after_connection`.
- Ajoute une compatibilité défensive si ce rendu est invoqué avec un seul argument par une intégration plus ancienne.
- La roadmap conserve la validation terrain du Hub Client sous Maintenant jusqu’au test sur un site client lié.

## 4.5.88 — 2026-09-04
- Ajoute dans **Déploiement à distance** un bouton **Télécharger Hub Client X.Y.Z**.
- Le bouton télécharge uniquement le ZIP Hub Client de la publication active, jamais la Suite complète.
- La version affichée est dynamique et suit automatiquement le paquet `hub_client` de la publication active.
- Le téléchargement exige une session administrateur AWM et un nonce WordPress; le SHA-256 du paquet est revérifié avant envoi.
- Chaque téléchargement manuel est journalisé dans le journal de sécurité Core.

## 4.5.87 — 2026-09-04
- Publie Hub AWM 4.5.48 et Tech AWM 1.2.0.
- Thech AWM réutilise désormais le moteur de recherche clients canonique au lieu d une table Sites parallèle.
- Le shell commun reconnaît les fiches ouvertes en contexte Tech et garde l onglet principal Thech AWM actif.
- La navigation Thech remplace Sites par Clients; IA, Consommation, Mémoire et Journal restent inchangés.
- Chaque fiche client peut maintenant afficher l onglet Tech injecté par le paquet autonome.
- Activation et permissions sont gérées à même la fiche client, toujours exclusivement côté Alliance.

# Changelog Core AWM

## 4.5.86 — 2026-09-04
- Ajoute **Tech AWM 1.1.0** comme dixième paquet physique officiel de la Suite.
- Le gestionnaire de mises à jour reconnaît `tech-awm/tech-awm.php`, son ZIP, sa version, son SHA-256 et son rollback.
- Ajoute un bootstrap de migration signé pour installer Tech AWM lors du premier passage depuis Core 4.5.85, puis l enregistrer dans la publication active.
- La Suite complète passe de 9 à 10 paquets physiques.
- Hub Client 1.11.5 doit être déployé avant la première installation distante de Tech AWM sur un site client.

## 4.5.85 — 2026-09-04

- Publie Hub AWM 4.5.46 / Thech AWM 1.0.2 dans la Suite unique 4.5.85.
- Ajoute au shell commun la couleur et l icône configurables de Thech AWM afin que son en-tête reprenne exactement le langage visuel des autres modules.
- Harmonise les écrans Thech Sites, IA, Consommation, Mémoire et Journal avec le design Premium partagé.
- Supprime le doublon du bouton Light/Dark lorsque le shell Core est déjà actif.
- Conserve Tech AWM directement dans Hub Client 1.11.4 et l activation exclusivement côté Alliance.
- Synchronise la roadmap et maintient la validation visuelle réelle sous Maintenant jusqu au test sur alliancewebmarketing.ca.

## 4.5.84 — 2026-09-04

- Reconnaît **Thech AWM** comme contexte administratif autonome au lieu de le traiter comme une page interne du Hub.
- Ajoute le shell Thech AWM avec les onglets Sites, IA, Consommation, Mémoire et Journal.
- Publie Hub AWM 4.5.45 / Thech AWM 1.0.1 dans la Suite unique 4.5.84.
- Conserve Thech intégré physiquement au paquet Hub et Tech AWM intégré au paquet Hub Client.
- Synchronise la roadmap publique avec le nouvel onglet principal Thech AWM.

## 4.5.83 — 2026-09-04

- Intègre les routes Connector privées de **Thech AWM / Tech AWM** dans Core sans ajouter de secret client supplémentaire.
- Authentifie `tech/status`, `tech/chat` et `tech/action-result` avec le jumelage Hub Client existant avant délégation au Hub.
- Publie **Hub AWM 4.5.44** et **Hub Client AWM 1.11.4** dans la Suite unique.
- Ajoute **Thech AWM 1.0.0** comme dixième module logique de la roadmap tout en conservant neuf paquets physiques dans la Suite.
- Conserve les écritures Elementor dans le moteur sécurisé Hub Client déjà livré avec snapshots et contrôle SHA-256.

## 4.5.82 — 2026-09-03

- Publie **Hub Client AWM 1.11.3**; CallTracker AWM reste en 1.10.0.
- Applique au routage client le modèle Premium adaptatif validé avec gros pictogrammes, typographie renforcée et stepper clair.
- Dérive tous les accents, contours, halos et fonds des couleurs configurées pour le client au lieu d imposer une palette fixe.
- Ajoute un contraste automatique pour le texte des CTA principaux.
- Condense l horaire dans deux tableaux et renforce l apparence de bouton de Voir la campagne, Configurer le routage et Enregistrer le routage.
- Synchronise la roadmap publique et les versions de la Suite.

## 4.5.81 — 2026-09-03

- Publie **Hub Client AWM 1.11.2**; CallTracker AWM reste en 1.10.0.
- Refonte compacte de **CallTracker → Routage** côté client : destinations, fuseau et débordement sont regroupés et les horaires occupent moins de hauteur.
- Remplace les champs d heure natifs par des listes 24 h par tranches de 15 minutes afin de supprimer le sélecteur navigateur blanc visible en thème sombre.
- Améliore les blocs fermetures spéciales, Message 2, responsive et action d enregistrement.
- Synchronise la roadmap publique et les versions de la Suite avec cette livraison UX.

## 4.5.80 — 2026-09-03

- Publie **Hub Client AWM 1.11.1** et **CRM AWM 1.6.15**; CallTracker AWM reste en 1.10.0.
- Ajoute le filtrage sécurisé `campaign_id` aux routes clientes Appels et Leads afin qu une fiche de campagne puisse lire uniquement ses propres données.
- Hub Client permet de cliquer sur une campagne et d ouvrir une fiche affichant son **nom**, ses **appels**, ses **formulaires** et son **CPL**.
- CRM protège les forfaits historiques : **10 $ + taxes** s applique uniquement aux nouveaux Funnels créés explicitement et jamais rétroactivement aux campagnes existantes.
- Synchronise la roadmap publique et les versions de la Suite avec cette livraison.

## 4.5.79 — 2026-09-02

- Publie **CallTracker AWM 1.10.0**, **CRM AWM 1.6.14** et **Hub Client AWM 1.11.0**.
- Ajoute les routes clientes sécurisées `client/funnels` et `client/funnels/create` afin que CRM demeure la source du service Funnel à 10 $/mois.
- Sépare la création du service, la préparation de la campagne et l achat du numéro; la facturation CRM ne démarre qu après attribution confirmée du numéro.
- Hub Client adopte le parcours **Nouveaux services → Nouveau funnel → Configuration du numéro → Formulaire/Webhook → Routage**.
- Étend la route cliente de routage aux horaires, jours fermés, fuseau, destination hors heures, débordement et délai sans exposer les secrets Twilio.
- Conserve les contrôles de propriété client, les confirmations d achat, les protections anti-double achat et les journaux Core.
- Synchronise la roadmap publique avec cette livraison tout en conservant la validation terrain sous Maintenant.

## 4.5.78 — 2026-09-02

- Publie CallTracker AWM 1.9.9 et Hub Client AWM 1.10.2.
- Ajoute la route publique Core `callink/v1/forms/webhook/{jeton}` déléguée à CallTracker, avec jeton 256 bits par funnel.
- Ajoute la route cliente authentifiée de test du webhook sans création de faux lead.
- Les formulaires externes sont attribués au bon funnel, stockés dans l historique CallTracker et intégrés aux Leads/CPL existants.
- Hub Client affiche l URL à copier, l état du dernier envoi et la documentation d installation directement dans l espace client.
- La roadmap publique est synchronisée avec cette livraison sans clôturer les validations terrain encore en cours.

## 4.5.77 — 2026-09-02

- Publie CallTracker AWM 1.9.8, CRM AWM 1.6.13 et Hub Client AWM 1.10.1.
- Ajoute les routes clientes sécurisées de recherche et d achat de numéros CallTracker.
- L achat client crée un Funnel CallTracker à 10 $/mois, sa campagne, son numéro et son service CRM associé.
- Aucun identifiant Twilio n est exposé au Hub Client; Core vérifie le client, le module CallTracker et la confirmation du prix avant l opération.
- La roadmap publique classe cette première autonomie Numéros/Funnel comme livrée et garde le routage client avancé comme prochaine livraison rapide.

## 4.5.76 — 2026-09-02

- Publie CallTracker AWM 1.9.7 et Hub AWM 4.5.43.
- Ajoute au routeur Core la route TwiML `callink/v1/routing-next` utilisée pour le débordement séquentiel signé par Twilio.
- Met à jour la roadmap publique avec le Lot C phase 1 livré et sa validation terrain maintenue sous Maintenant.
- Conserve équipes, priorités, stratégies multi-tentatives, modèles et test simulé dans le Lot C phase 2.

## 4.5.75 — 2026-09-02

- Publie Hub AWM 4.5.42.
- Roadmap publique : les états **Livré**, **Maintenant**, **Prochaines étapes** et **Futur** ouvrent maintenant une fenêtre popup de lecture détaillée.
- Met à jour le registre central des versions, la publication active et les dernières implantations afin que cette amélioration soit visible immédiatement sur `/hub/roadmap/`.

## 4.5.74 — 2026-09-02

- Met à jour la roadmap publique CallTracker sans modifier le runtime CallTracker 1.9.6.
- Porte la section **CallTracker → Futur** à **20 orientations distinctes**.
- Ajoute le retour automatique des conversions qualifiées vers Google Ads et l attribution Meta Ads + Microsoft Ads.
- Ajoute le Call Whisper contextuel, le constructeur visuel des parcours d appel et le routage intelligent par compétence, région et disponibilité.
- Ajoute le contrôle qualité des appels assisté par IA, la détection de spam/fraude et le centre d intelligence des anomalies CallTracker.
- Conserve les éléments **Maintenant** et **Prochaines étapes** existants afin de ne pas classer comme livrées les validations terrain, le Lot C, le Lot D ou le Lot E.
- Met à jour le contrat `roadmap_sync` afin que la vraie page `https://alliancewebmarketing.ca/hub/roadmap/` reçoive ces orientations lors du déploiement de la Suite.

## 4.5.73 — 2026-08-31

- Publie Studio AWM 1.14.0 dans la Suite complète.
- Transforme Studio → Optimisation globale en workflow SEO de production avec **Optimiser tout**, **SEO rapide** et passage SEOPress immédiat.
- Les optimisations globales sont exécutées séquentiellement pour limiter les timeouts et chaque écriture SEOPress conserve le snapshot Hub Client 1.10.0.
- Ajoute une Recherche SEO rapide fondée sur le contenu réel, le service/sujet et la zone fournis, avec mot-clé principal, variantes, intention, H1 et questions faciles à réutiliser.
- Ajoute l optimisation ciblée bloc par bloc pour les pages Elementor existantes avec plan révisable et conservation des widgets/formulaires/éléments non ciblés.
- Les pages protégées sont exclues d Optimiser tout; URL, canonical et indexation restent sous contrôle humain.
- Met à jour le registre des versions, le paquet Studio embarqué, les Dernières implantations, Vision par module et Plan de développement via le contrat `roadmap_sync` vers `https://alliancewebmarketing.ca/hub/roadmap/`.

## 4.5.72 — 2026-08-31

- Publie Hub AWM 4.5.41 et Studio AWM 1.13.1.
- Harmonise le menu WordPress AWM : logo Alliance commun, pictogramme par module, dimensions identiques et ordre Core → Hub → CRM → CallTracker → Stats → Assistant → Soutien → Studio.
- Studio affiche maintenant le libellé **Studio AWM** et Core reconnaît son contexte de shell séparément de Hub.
- Corrige la roadmap Hub Client : version 1.10.0 et snapshots/restauration reclassés en Livré.
- Rend les versions de Suite strictement croissantes dans Core → Mises à jour.
- Exige les 9 modules et un contrat de synchronisation `roadmap_sync` dans `manifest.json` pour toute future publication.
- Ajoute la livraison 4.5.72 aux Dernières implantations et harmonise Vision par module / Plan de développement.

## 4.5.71 — 2026-08-31

- Publie Studio AWM 1.13.0 et Hub Client AWM 1.10.0.
- Ajoute la reprise des pages Elementor existantes depuis Studio → Optimisation globale.
- Ajoute un plan de modification IA révisable avant application, limité aux widgets/réglages autorisés et sans suppression automatique.
- Ajoute des snapshots restaurables avant écriture Elementor ou SEOPress, avec garde de concurrence par empreinte SHA-256.
- Réutilise le moteur SEO Studio pour préparer les valeurs SEOPress des pages existantes tout en laissant URL, canonical et indexation sous contrôle humain.
- Met à jour la roadmap publique, Vision par module, Plan de développement, versions et paquet Studio embarqué.
- Hub AWM 4.5.40, CRM 1.6.12, CallTracker 1.9.6, Stats 1.3.0, Assistant 1.5.0 et Soutien 1.5.0 restent inchangés.

## 4.5.70 — 2026-08-31

- Publie Studio AWM 1.12.0 et Hub AWM 4.5.40.
- Embarque le paquet Studio 1.12.0 vérifié SHA-256 pour installer la galerie autonome même après une mise à jour partielle.
- Ajoute à la roadmap publique la livraison **Galerie serveur autonome des maquettes Studio 4.5.70**.
- Met à jour les versions, les dernières implantations, la Vision par module et le Plan de développement Studio.
- Maintient Core comme fournisseur exclusif de sécurité et de connexions; aucune préparation, maquette, image, configuration IA, analyse ou historique Studio n'est déplacé dans Core.

## 4.5.69 — 2026-08-31

- Publie Studio AWM 1.11.1 et Hub AWM 4.5.39.
- Embarque le paquet Studio 1.11.1 vérifié SHA-256 afin de réparer automatiquement une installation partielle.
- Studio reprend exclusivement la route `callink-studio`, son rendu et ses actions AJAX; l'ancien contrôleur Hub est neutralisé.
- Le bouton **Voir les 3 maquettes** possède une URL serveur complète et le panneau utilise des identifiants exclusifs à Studio.
- Hub 4.5.39 force le retrait des anciennes versions contenant encore le moteur Studio.
- Core ne lit ni n'écrit aucune préparation, maquette, image, profil, audit, historique ou configuration IA Studio.
- Les seuls services partagés avec Studio restent la sécurité et les connexions.

## 4.5.68 — 2026-08-30

- Sépare complètement Studio AWM du code métier de Core et de Hub.
- Ajoute Studio AWM 1.11.0 comme module autonome avec son propre ZIP, sa version et ses permissions.
- Core partage seulement la sécurité (accès, permissions, coffre et journal de sécurité) et les connexions sécurisées utilisées par Studio.
- Ajoute le transport générique et limité `AWM_Core_Remote_Client` pour les routes Studio autorisées vers Hub Client.
- Ajoute une migration de transition depuis 4.5.67 : Core installe une fois le paquet Studio autonome embarqué, puis les versions suivantes utilisent le paquet normal `studio-awm-X.Y.Z.zip` de la Suite.
- Le gestionnaire de mises à jour sait ensuite installer, inventorier, mettre à jour et restaurer Studio comme tout autre module.
- Aucune préparation, maquette, image, profil, audit, historique ni configuration IA Studio n'est stocké par Core.

## 4.5.67 — 2026-08-29

- Publie Hub AWM 4.5.37 et Studio AWM 1.10.4.
- Corrige la disparition du bloc Maquettes lorsque l URL ne contient plus l identifiant de préparation.
- Ajoute une reprise automatique, un sélecteur des préparations récentes et un mode nouvelle page explicite.
- Rend les trois variantes A/B/C et les boutons Écran, Tablette et Mobile côté serveur avant toute exécution JavaScript.

## 4.5.66 — 2026-08-29

- Publie Hub AWM 4.5.36 et Studio 1.10.3 afin de forcer le remplacement du build réellement exécuté dans WordPress.
- Studio reconstruit automatiquement le grand aperçu lorsque le HTML actif ne contient que les trois miniatures, la barre des formats et les actions.
- L actif `studio-preview.js` utilise maintenant une empreinte SHA-256 de son contenu plutôt qu un simple horodatage.
- Core conserve l empreinte SHA-256 de chaque paquet local installé et peut reconnaître un nouveau build portant la même version lors des publications suivantes.
- La sauvegarde et le rollback restaurent aussi l empreinte du build précédent.
- Les requêtes d installation locales disposent d une limite adaptée, d erreurs réseau lisibles et poursuivent les modules suivants même lorsqu un module échoue.

## 4.5.65 — 2026-08-28

- Publie Studio 1.10.2 et Hub AWM 4.5.35 avec le véritable visualiseur résilient rendu côté serveur.
- Corrige l erreur de conditionnement de la Suite 4.5.64 : l archive distribuée contenait une implantation antérieure du visualiseur malgré les mêmes numéros de version.
- Force une nouvelle installation par incrément de version afin que Core ne classe plus le correctif comme déjà à jour.
- Invalide les caches de fichiers PHP et OPcache après installation ou rollback d un module.
- Conserve Hub Client 1.9.5, CRM 1.6.12, CallTracker 1.9.6, Stats 1.3.0, Assistant 1.5.0 et Soutien 1.5.0 sans changement.

## 4.5.64 — 2026-08-28

- Publie Studio 1.10.1 et Hub AWM 4.5.34.
- Rend systématiquement la maquette sélectionnée côté serveur dans le grand aperçu Studio.
- Ajoute des replis HTML fonctionnels pour A/B/C, Écran/Tablette/Mobile, plein écran et approbation.
- Charge le contrôleur de prévisualisation dans l en-tête et utilise l empreinte du fichier pour invalider les anciens caches.
- Synchronise variante, format, états ARIA, champ d approbation et URL sans dépendre du script inline historique.
- Retire l observation globale du DOM afin d éviter toute réinitialisation en boucle du grand aperçu.
- Hub Client 1.9.5 et les autres modules restent inchangés.

## 4.5.63 — 2026-08-27

- Publie Studio 1.10.0 et Hub AWM 4.5.33.
- Ajoute un script externe versionné pour fiabiliser les trois maquettes et les boutons Écran, Tablette et Mobile.
- Remplace les pseudo-liens de maquette par de vrais boutons accessibles et ajoute une vue plein écran.
- Ajoute le panneau Page générée et les raccourcis directs vers la page, Elementor, le SEO, le projet, une nouvelle création et une correction.
- Ajoute un contrôle qualité automatique avant publication basé sur les résultats réels du site client.
- Conserve rendu validé, nombre d éléments, médias, score SEO, SEOPress et moteur de layout dans la préparation.
- Ajoute les orientations Studio approuvées au Futur de la roadmap.
- Hub Client 1.9.5 reste compatible et inchangé.

## 4.5.62 — 2026-08-27

- Publie Studio 1.9.0 et Hub AWM 4.5.32.
- Corrige la zone de maquette vide : l aperçu complet est maintenant forcé visible avant Elementor.
- Ajoute trois maquettes réellement sélectionnables par groupe : A Conversion, B Premium et C Éditoriale.
- Rend fonctionnelles les vues Écran, Tablette et Mobile avec largeurs et comportements responsive distincts.
- L approbation enregistre la proposition sélectionnée comme blueprint officiel de la page.
- « Générer 3 autres propositions » crée un nouveau groupe; une correction par prompt part de la maquette sélectionnée.
- Migre automatiquement les préparations 1.8.0 existantes vers le nouveau système à trois propositions.
- Roadmap, documentation et Publication active synchronisées.

## 4.5.61 — 2026-08-27
- Ajoute le cycle d approbation des maquettes Studio avant création Elementor.
- Ajoute la génération de variantes et les corrections de maquette par prompt.
- Bloque la création unitaire tant que la maquette n est pas approuvée.
- Ajoute une publication finale contrôlée après vérification du brouillon réel.
- Publie Studio 1.8.0 et Hub Client 1.9.5 dans le registre central.

## 4.5.60 — 2026-08-27
- Publie Studio 1.7.0, Hub 4.5.30 et Hub Client 1.9.4.
- Corrige le moteur Page de référence afin que le profil analysé modifie réellement le blueprint et le rendu Elementor.
- Extrait Hero, largeur, alternances image/texte, densité, espacements, rayons, CTA et effets depuis la référence.
- Applique le niveau d inspiration Légère / Moyenne / Élevée avant la création.
- Conserve exclusivement les couleurs, typographies, textes et médias du client.
- Réapplique aussi la référence aux préparations Studio déjà existantes lors de leur enregistrement.

## 4.5.59 — 2026-08-27
- Publie Studio 1.6.0 et Hub 4.5.29; Hub Client 1.9.3 reste compatible.
- Sépare visuellement et fonctionnellement **Créer une page** et **Batch local** dans Studio.
- Ajoute quatre espaces clairs : Créer une page, Batch local, Optimiser les pages et Historique.
- La création unitaire suit trois étapes simples et ne demande plus aucun champ Batch.
- Les options avancées sont repliées afin de conserver un formulaire principal court.
- Le diagnostic du site et la configuration IA restent communs aux espaces Studio.
- Roadmap, documentation et Publication active harmonisées.

## 4.5.58 — 2026-08-27
- Publie Studio 1.5.0, Hub 4.5.28 et Hub Client 1.9.3.
- Ajoute l analyse sécurisée d une page publique de référence et trois niveaux d inspiration.
- Ajoute un profil de design contrôlé au blueprint : hauteur Hero, espacements, rayons, animations et effets de survol.
- Applique la typographie Elementor du client aux contenus générés.
- Interdit explicitement la copie du texte, des images, de la marque et des couleurs de la référence.
- Synchronise roadmap, documentation et Publication active.

## 4.5.57 — 2026-08-27
- Publie Studio 1.4.0, Hub 4.5.27 et Hub Client 1.9.2.
- Ajoute « ✦ Tout générer avec l IA » après saisie du mot-clé principal et des variantes.
- Rend éditables avant lancement tous les blocs du blueprint ainsi que titre, ALT, légende, description et prompt de chaque photo.
- Ajoute les modes Photos IA, Photos du client et Mixte pour éviter toute génération inutile.
- Affiche Studio avec sa propre version dans Mises à jour AWM tout en indiquant qu il reste intégré à Core, Hub et Hub Client.
- Roadmap, documentation et Publication active harmonisées.

# Changelog Core AWM

## 4.5.56 — 2026-08-27
- Publie Studio 1.3.0 et Hub 4.5.26.
- Ajoute la longueur cible des blocs de contenu aux blueprints Studio et à leur optimisation IA.
- Le moteur SEO génère maintenant 5 à 8 variantes du mot-clé principal.
- Ajoute les endpoints AJAX sécurisés nécessaires au flux une page et à la sauvegarde avant lancement.
- Le loader AWM suit contenu, images, SEO, Elementor, SEOPress et validation.
- Roadmap, documentation et Publication active harmonisées avec la Suite 4.5.56.

## 4.5.55 — 2026-08-27
- Studio 1.2.0 ajoute une préparation complète avant lancement avec score SEO visuel et tableau SEOPress modifiable.
- Ajoute les suggestions ✦ IA champ par champ avec validation humaine explicite.
- Conserve les aperçus images côté Alliance et permet la régénération individuelle d une image par prompt.
- Ajoute le mode Batch local jusqu à 12 villes avec traitement séquentiel, score SEO et mesure de similarité.
- Ajoute l audit signé de toutes les pages WordPress/Elementor et la révision SEOPress des pages existantes.
- Protège les pages système par confirmation explicite avant toute modification SEO.
- Corrige les valeurs image_quality/image_size absentes ou invalides sans avertissement PHP.
- Publie Hub 4.5.25 et Hub Client 1.9.1; roadmap, documentation et Publication active sont harmonisées.

## 4.5.54 — 2026-08-27
- Studio 1.1.0 ajoute le SEO SEOPress automatique pour les nouvelles landing pages.
- Génère au moins deux images originales par page via le modèle image configuré dans Core.
- Nomme les médias `nom-de-la-page-0001.jpg`, `-0002.jpg` et suivants; `0001` devient l’image mise en avant.
- Transmet à Hub Client seulement les images encodées et métadonnées contrôlées, jamais la clé API.
- Publie Hub 4.5.24 et Hub Client 1.9.0; roadmap, documentation et Publication active sont harmonisées.


## 4.5.53 — 2026-08-27
- Corrige le flux Studio ayant pu produire un brouillon Elementor blanc.
- Publie Hub Client 1.8.9 avec détection Containers / Sections-Columns et validation du rendu frontend.
- Ajoute la commande sécurisée de réparation d un brouillon Studio existant.
- Enregistre le moteur de rendu, l aperçu, le nombre d éléments et l état de validation dans l historique Studio.
- Publie Hub AWM 4.5.23 et synchronise roadmap, documentation et Publication active.

## 4.5.52 — 2026-08-27
- Publie Hub AWM 4.5.22 avec une documentation publique entièrement harmonisée au thème sombre Alliance de la roadmap.
- Synchronise les versions courantes des neuf modules dans la documentation.
- Documente Studio comme module officiel de création WordPress/Elementor.
- Corrige la documentation CRM : WHMCS devient un connecteur facultatif plutôt qu une dépendance obligatoire.
- Clarifie les responsabilités Core / Hub / Hub Client / Soutien et les règles de sécurité.


## 4.5.51 — 2026-08-27
- Place le Plan de développement interactif avant Dernières implantations.
- Conserve les neuf modules dans un sélecteur unique et synchronisé.
- Expose un seul grand graphique dynamique avec Livré, Maintenant, Prochaines étapes et Futur.
- Synchronise les descriptions détaillées du module choisi sans dupliquer les données de roadmap.
- Publie Hub AWM 4.5.21 et maintient Studio comme neuvième module officiel.

## 4.5.50 — 2026-08-27
- Ajoute un contexte visuel Studio au shell administratif partagé.
- Studio possède désormais son accent, son icône et son en-tête propres au lieu d'hériter du contexte Hub.
- Le mode sombre/clair Studio suit exactement les réglages globaux Alliance.

## 4.5.50 -- 2026-08-27
- Ajoute **Studio AWM** comme chantier prioritaire de la Suite.
- Ajoute le canal serveur-à-serveur sécurisé Core → Hub Client pour les commandes Studio.
- Core valide l’approbation du client, le domaine lié et le secret local chiffré avant toute action distante.
- Ajoute l’analyse technique du site : Elementor, Elementor Pro, thème, WordPress, PHP, logo et palette disponible.
- Ajoute la création distante d’un brouillon WordPress/Elementor avec journalisation centrale et historique par client.
- Interdit la publication directe dans ce premier lot; Studio crée uniquement des brouillons.
- N’envoie aucun secret Core/IA au site client et n’autorise aucun PHP, JavaScript ou HTML arbitraire provenant du brief.
- Ajoute le moteur IA Studio dans Core via une API serveur-à-serveur avec sortie JSON structurée, modèle configurable et clé chiffrée dans le coffre Core.
- Utilise automatiquement les modèles métier contrôlés comme repli si le moteur IA est absent ou indisponible.
- Place maintenant la validation terrain, la modification conversationnelle et les snapshots/rollback dans les prochaines priorités.

---

## 4.5.48 -- 2026-08-27
- Détaille dans **Futur — CallTracker** les douze axes fonctionnels approuvés après comparaison concurrentielle, sans lancer leur développement.
- Ajoute DNI, parcours du lead, attribution marketing avancée, SMS bidirectionnel et automatisations SMS.
- Ajoute moteur de règles, qualification/score, Conversation Intelligence IA et assistant téléphonique IA 24/7.
- Ajoute centre d intégrations, attribution jusqu au revenu CRM et historique unifié des conversations.
- Remplace l ancien item générique « Qualité, attribution et conversion CRM » afin d éviter les doublons et de conserver un comptage Futur exact.
- Conserve les Lots C, D et E sous **Prochaines étapes**; aucune fonction CallTracker 1.9.6 n est marquée livrée artificiellement.
- Harmonise roadmap centrale, Publication active, notes de livraison et manifeste avec la Suite AWM 4.5.48.

## 4.5.47 -- 2026-08-27
- Publie Hub AWM 4.5.18 avec le tableau de progression compact de `/hub/roadmap/`.
- Calcule un résumé global depuis Livré, Maintenant, Prochaines étapes et Futur pour les huit modules.
- Calcule l avancement actif sans inclure Futur dans le dénominateur, tout en conservant Futur dans la barre et les roues.
- Ajoute un état opérationnel dérivé des éléments Maintenant : Stable, En développement, Validation ou Attention requise.
- Compare le pourcentage livré à l instantané publié de la Suite 4.5.46 et affiche l évolution en points.
- Replie l historique Livré après cinq éléments dans le Plan détaillé et dans Vision par module.
- Synchronise roue, Plan détaillé, navigation et Vision par module sur un seul module actif.
- Conserve les quatre dernières implantations, la navigation historique, les ancrages publics et la palette Alliance bleu nuit.
- Harmonise roadmap centrale, changelogs, notes de publication, manifeste et contrôles d intégrité avec la Suite AWM 4.5.47.

## 4.5.46 -- 2026-08-27
- Publie Hub AWM 4.5.17 avec la nouvelle identite visuelle sombre de la roadmap publique.
- Harmonise les surfaces, cartes, bordures, boutons, formulaires et etats interactifs avec la palette bleu nuit Alliance.
- Remplace le vert et l orange des roues par trois nuances de bleu pour **Livre**, **Maintenant** et **Prochaines etapes**; **Futur** reste gris.
- Simplifie les titres visibles des modules en Core, Hub, Hub Client, CallTracker, CRM, Soutien, Assistant et Stats, sans repeter le suffixe AWM.
- Conserve le calcul dynamique des pourcentages et proportions depuis le registre central.
- Harmonise roadmap centrale, changelogs, notes de publication, manifeste et controles d integrite avec la Suite AWM 4.5.46.

## 4.5.45 — 2026-08-25
- Publie Hub AWM 4.5.16 et la refonte dynamique de la roadmap publique.
- Limite **Dernières implantations** aux quatre versions les plus récentes et ajoute une navigation par groupes de quatre.
- Calcule un cercle segmenté pour chacun des huit modules à partir des statuts réels **Livré**, **Maintenant**, **Prochaines étapes** et **Futur**.
- Affiche le pourcentage livré, les compteurs de chaque état et un détail regroupé par module au clic.
- Conserve les ancrages publics historiques de tous les modules et la section **Vision par module**.
- Ajoute la navigation clavier, le comportement responsive et un rendu local sans dépendance graphique externe.
- Harmonise roadmap centrale, changelogs, notes de publication, manifeste et contrôles d’intégrité avec la Suite AWM 4.5.45.

## 4.5.44 — 2026-08-25
- Publie CallTracker AWM 1.9.6 avec une bascule globale contrôlée de l’ancienne plateforme vers AWM.
- Reprend par lots tous les numéros des campagnes actives, y compris ceux dont les appels entrants sont désactivés, afin qu’aucun webhook legacy ne reste maître.
- Résout les Phone Number SID, remplace le VoiceUrl et le callback de statut, retire VoiceFallbackUrl/VoiceApplicationSid puis vérifie la ressource Twilio après écriture.
- Ajoute le verrou **BASCULE AWM** : lorsque tous les numéros sont conformes, Laravel et les imports CPL historiques deviennent lecture seule jusqu’à réouverture explicite.
- Référence l’accès API Google approuvé pour le futur lot CPL / Google Ads, sans déplacer les secrets hors du coffre Core.
- Harmonise roadmap centrale, roadmap CallTracker, changelogs et Publication active avec la Suite AWM 4.5.44.

## 4.5.43 — 2026-08-25
- Publie CallTracker AWM 1.9.5 avec resynchronisation automatique des campagnes existantes après modification du numéro de réception.
- Référence la vérification du Phone Number SID, la reprise du webhook entrant AWM et l'état de routage visible dans l'éditeur.
- Journalise le succès ou l'échec de la resynchronisation sans faire de WHMCS ou de Twilio une source de vérité métier.
- Publie Hub AWM 4.5.15 : les requêtes Heartbeat/autosave de fond ne déclenchent plus le loader « Récupération des données » toutes les ~30 secondes.
- Harmonise roadmap centrale, roadmaps Hub/CallTracker, changelogs et Publication active avec la Suite 4.5.43.

## 4.5.42 — 2026-08-25

- Le loader Core de secours ignore les notices WordPress `lost-connection` / stockage local dans l'éditeur CallTracker au lieu de les présenter comme erreurs AWM.
- Publie CallTracker AWM 1.9.4 et Hub AWM 4.5.14 avec l'état de connexion intégré à la barre d'enregistrement des campagnes.
- Harmonise roadmap centrale, roadmaps modules, changelogs et Publication active avec la Suite 4.5.42.

---

## 4.5.41 — 2026-08-25

- Publie CallTracker AWM 1.9.3 et Hub Client AWM 1.8.7.
- Ajoute une route cliente authentifiée pour la lecture sécurisée des enregistrements CallTracker.
- Vérifie l appartenance de l appel au client avant de demander le média à Twilio.
- Stream le fichier temporaire côté Alliance et retire l URL Twilio brute du contrat Appels.
- Référence l idempotence, les statuts monotones, la file de reprise, l UTC canonique et le CPL par fuseau de campagne.
- Déplace le Lot B CallTracker sous Livré dans la roadmap centrale et conserve les essais Alliance/Twilio sous Maintenant.
- Harmonise changelogs, roadmaps et notes de Publication active avec la Suite 4.5.41.

---

## 4.5.40 — 2026-08-25

- Publie CRM AWM 1.6.12 avec fiches responsives pour le catalogue Services et abonnements.
- Référence les couleurs configurables des catégories et leur contraste automatique.
- Journalise les changements de couleurs de catégories depuis CRM.
- Référence la progression intégrée des opérations Services et abonnements et les résultats repris par le loader AWM.
- Conserve CallTracker AWM 1.9.2 et son chantier terrain sous **Maintenant** sans le marquer terminé artificiellement.
- Harmonise roadmap centrale, roadmap CRM, changelogs et Publication active avec la Suite 4.5.40.

---

## 4.5.39 — 2026-08-25

- Ajoute la barrière fail-closed du CPL client pour CallTracker AWM 1.9.2.
- L’API cliente sépare les campagnes approuvées des campagnes en attente et ne retourne aucune ligne CPL pour une campagne non approuvée.
- Ajoute au contrat API un état de validation avec disponibilité, campagnes approuvées, campagnes en attente et total du client.
- Refuse toute ouverture implicite si la classe de validation CallTracker est absente.
- Conserve les contrôles de propriété client et empêche toute substitution par les données d’une autre campagne.
- Journalise les approbations, invalidations, clôtures et réouvertures de migration.
- Met à jour la roadmap centrale et la Publication active pour CRM AWM 1.6.11, CallTracker AWM 1.9.2, Hub AWM 4.5.13 et Hub Client AWM 1.8.6.

---

## 4.5.38 — 2026-08-25

- Publie CRM AWM 1.6.10 et son catalogue autonome de services et abonnements indépendant des clients.
- Harmonise la roadmap centrale avec la séparation Catalogue général / Attributions clientes et publie la propagation facultative des valeurs du catalogue vers les services clients liés, sans modifier leur date, état ou autorisation de facturation.
- Ajoute des exclusions persistantes pour les services WHMCS supprimés localement afin qu’une synchronisation ultérieure ne puisse pas les recréer.
- Journalise la création et la levée d’une exclusion de service externe.
- Conserve Hub AWM comme propriétaire de l’application au portail et CRM comme propriétaire des conditions commerciales.
- Maintient le Lot A CallTracker AWM sous **Maintenant** dans la roadmap centrale.

---

## 4.5.37 — 2026-08-25

- Publie CRM AWM 1.6.9 et sa liste des services et abonnements déjà appliqués.
- Ajoute la protection des modifications locales pour les services reliés à WHMCS : la synchronisation conserve un instantané externe sans réécrire le registre CRM.
- Documente les nouveaux filtres, indicateurs, cycles de facturation et actions de modification des services.
- Limite les sélecteurs de facture et de soumission aux services appliqués au client dans Hub AWM.
- Référence l’audit et le plan d’avancement CallTracker AWM 1.9.1 dans la roadmap centrale.
- Met à jour la roadmap publique et la Publication active de la Suite 4.5.37.

---

## 4.5.36 — 2026-08-25

- Accompagne CRM AWM 1.6.8 avec les titres français des modèles courriel.
- Publie l’activation/désactivation rapide et cliquable directement dans **CRM AWM → Courriels**.
- Conserve les noms WHMCS comme références techniques sans les utiliser comme titres principaux.
- Journalise les changements d’état des modèles dans le journal de sécurité Core.
- Met à jour la roadmap publique et la Publication active de la Suite 4.5.36.

---

## 4.5.35 — 2026-08-25

- Accompagne CRM AWM 1.6.7 et corrige l’écran Courriels qui affichait zéro modèle.
- Publie le nouveau registre interne valide des modèles et l’amorçage automatique des 86 modèles AWM.
- Documente la réparation automatique d’un catalogue incomplet et la conservation des textes personnalisés.
- Maintient WHMCS comme connecteur facultatif; aucun import n’est requis pour voir ou modifier les modèles.
- Met à jour la roadmap publique et la Publication active de la Suite 4.5.35.

---

## 4.5.34 — 2026-08-25

- Renforce le transport API WHMCS et distingue les erreurs HTTP 401, 403, 406, 429 et 5xx.
- Ajoute un diagnostic 403 orienté vers l’adresse IP autorisée, la clé d’accès API et les permissions du compte administrateur.
- Tente les champs d’authentification modernes puis historiques sans contourner les restrictions de WHMCS.
- Permet un snapshot partiel des familles de modèles courriel avec avertissements par famille facultative.
- Harmonise le shell CRM avec les onglets réels de CRM AWM 1.6.6 et retire l’ancien onglet Soutien.
- Supprime la navigation CRM dupliquée : le shell Core devient l’unique navigation principale du module.
- Met à jour la roadmap publique et la Publication active de la Suite 4.5.34.

---

## 4.5.33 — 2026-08-25

- Ajoute `GetEmailTemplates` à la liste blanche du connecteur WHMCS pour une lecture contrôlée du catalogue de modèles.
- Expose à CRM AWM un snapshot en lecture seule des modèles général, produit, domaine, facture et affiliation.
- Exclut explicitement les modèles support/ticket afin de préserver la séparation avec Soutien AWM.
- Le snapshot conserve nom, type, identifiant, sujet, langue, état et, uniquement lorsqu’il est fourni par WHMCS, le corps du message.
- Aucune modification d’un modèle CRM n’est réécrite dans WHMCS; Core reste seulement le gardien du connecteur.
- Roadmap centrale harmonisée avec CRM AWM 1.6.5 : services facturables, centre de courriels, séparation Soutien/CRM et corrections CSS.

---

## 4.5.32 — 2026-08-25

- Publie la nouvelle série de numérotation des factures natives CRM : `28102` + séquence (`281020001`, `281020002`, ...), sans renumérotation des documents existants.
- Accompagne CRM AWM 1.6.4 pour la migration détaillée des crédits et remboursements WHMCS historiques.
- Enrichit le snapshot de migration avec `GetTransactions` filtré par facture lorsque WHMCS est connecté.
- Conserve `amountin`, `amountout`, frais, description, `invoiceid` et `refundid` afin que CRM distingue encaissement et remboursement au lieu de déduire l’historique du seul statut de facture.
- Marque explicitement si le détail des remboursements est connu et conserve un repli prudent sur `GetInvoice`/archive lorsque le détail officiel n’est pas disponible.
- Ajoute l’identifiant de ligne WHMCS au snapshot des articles pour améliorer la traçabilité fiscale.
- Maintient le verrou financier 4.5.31 : après migration, WHMCS reste uniquement une source de comparaison et ne peut pas réécrire la comptabilité CRM.
- Met à jour la roadmap publique pour Core 4.5.32 et CRM AWM 1.6.4.

---

## 4.5.31 — 2026-08-25

- Accompagne CRM AWM 1.6.3 pour la migration financière contrôlée des factures WHMCS historiques.
- Ajoute un snapshot de migration de facture avec contrôle de propriétaire et lecture détaillée `GetInvoice` lorsque WHMCS est disponible.
- Utilise l’archive locale comme repli et expose des indicateurs permettant au CRM de refuser une migration ambiguë.
- Lorsqu’une facture porte le verrou de migration, une synchronisation WHMCS ultérieure n’écrase plus son total, son solde, ses paiements ni son statut CRM.
- Le même verrou s’applique aux lectures détaillées de facture afin qu’aucun chemin du connecteur ne puisse reprendre la propriété financière après la bascule.
- Conserve le dernier total, solde et statut observés côté WHMCS et marque une dérive au lieu de l’appliquer.
- Remplace la confirmation navigateur de l’importation WHMCS par une confirmation intégrée dans l’interface AWM.
- Met à jour la roadmap publique pour Core 4.5.31 et CRM AWM 1.6.3.

---

## 4.5.30 — 2026-08-24

- Met à jour le registre de Suite pour CRM AWM 1.6.2 et Hub Client AWM 1.8.5.
- Calcule les soldes de factures CRM après paiements et avoirs.
- Reconnaît les statuts Réglée et Créditée dans les résumés de facturation du Hub.
- Expose le total des avoirs dans le résumé client.
- Bloque une tentative de paiement lorsqu’une facture native CRM n’a plus de solde exigible.
- Conserve les passerelles de paiement natives/tokenisées comme prochaine étape; aucune donnée de carte n’est stockée dans Core.
- Harmonise la roadmap publique avec les nouveaux avancements CRM et Hub Client.
- Le diagnostic de santé classe maintenant WHMCS comme connecteur **optionnel** : son absence est neutre et ne crée plus un avertissement système.

---

# Changelog

## 4.5.50 — 2026-08-27
- Ajoute un contexte visuel Studio au shell administratif partagé.
- Studio possède désormais son accent, son icône et son en-tête propres au lieu d'hériter du contexte Hub.
- Le mode sombre/clair Studio suit exactement les réglages globaux Alliance.
 — Core AWM

## 4.5.29 — 2026-08-24

- Met à jour le registre public de la Suite pour CRM AWM 1.6.1.
- Documente comme livrées les lignes multiples, les taxes configurables figées par document et la facturation récurrente native CRM.
- La route client des factures continue d’exposer le payload CRM sans dépendance WHMCS; les détails de lignes ajoutés par CRM sont conservés.
- Maintient Core comme couche de sécurité/API seulement : aucune logique de calcul fiscal ou de récurrence n’est déplacée hors de CRM.
- Conserve dans la roadmap les prochaines étapes CRM : avoirs/remboursements, permissions contacts, PDF natifs, paiements tokenisés, pipeline et fonctions opérationnelles futures.
- Aucun changement de permission, session, secret ou contrat de route publique.

## 4.5.28 — 2026-08-24

- Remplace la confirmation navigateur de **Mettre à jour les modules Alliance** par une confirmation intégrée au loader de la carte Mises à jour.
- Affiche avant installation la Suite cible, les modules concernés et les transitions de versions, avec actions **Démarrer l’installation** et **Annuler**.
- Conserve la progression, les erreurs et l’état final dans le même composant AWM sans `alert()` ni `confirm()` natif sur la page Mises à jour.
- Harmonise aussi le déploiement distant, la suspension de publication et les rollbacks de cette page avec des confirmations contextuelles intégrées.
- Core reste installé en dernier et la page n’est rechargée automatiquement que si la mise à jour Core a réellement réussi.
- Met à jour la roadmap publique avec Core AWM 4.5.28; les versions des sept autres modules restent inchangées.


## 4.5.27 — 2026-08-24

- Fait de CRM AWM la source prioritaire de la route client des factures.
- Accompagne la création/édition de clients natifs CRM, les champs personnalisés et les rappels assignables de CRM AWM 1.6.0.
- Lors d’une synchronisation WHMCS optionnelle, rapproche une fiche CRM existante par courriel avant de créer un doublon et conserve sa source CRM native.
- Le résumé Hub calcule les soldes natifs sans dépendre de la disponibilité d’une passerelle de paiement.
- La route de paiement vérifie la propriété de la facture locale avant de déléguer à un fournisseur.
- Ajoute le point d’extension sécurisé `awm_crm_native_payment_url` pour une future passerelle native hébergée/tokenisée.
- Conserve WHMCS seulement comme connecteur de compatibilité pour les factures historiques importées.
- Marque les factures synchronisées depuis WHMCS comme `whmcs_import` et conserve la date de paiement lorsqu’elle est disponible.
- Met à jour la roadmap publique avec Core 4.5.27 et CRM AWM 1.6.0 autonome.


## 4.5.26 — 2026-08-24

- Harmonise la roadmap publique avec les publications actives, changelogs, roadmaps internes et fonctions présentes dans les huit modules.
- Ajoute CRM 1.5.0 comme livré pour la création de factures WHMCS et CRM 1.5.2 pour l’exclusion visuelle des clients tombstonés.
- Marque comme livrés dans Stats la mesure autonome du trafic, les formulaires et les conversions; conserve la validation réelle de collecte comme travail actuel.
- Marque comme livrés dans Assistant l’historique des analyses et la validation groupée des pages Web.
- Marque comme livrés dans Soutien le fil complet, la réanalyse guidée et l’ouverture du prochain ticket prioritaire.
- Ajoute explicitement dans Hub Client la connexion WordPress locale autorisée et enrichit la Facturation dans Mon compte.
- Ajoute explicitement dans Hub le routage/audio CallTracker et dans CallTracker les retours d’opérations via le loader.
- Aucun changement de table, route publique, permission, secret, session ou donnée métier.

## 4.5.25 — 2026-08-24

- Étend le contrat « aucun bandeau » à toutes les pages AWM, y compris les pages Core.
- Ajoute un loader Core de secours lorsque le loader visuel Hub n’est pas disponible.
- Masque les notices WordPress, update nags et promotions tierces résiduelles sur les écrans AWM.
- Convertit les confirmations internes Core en résultats consommables par le loader.
- Normalise les soldes WHMCS importés pour les statuts fermés afin de fiabiliser les KPI CRM.
- Met à jour la roadmap publique avec Core 4.5.25, Hub 4.5.12, CRM 1.5.3 et Hub Client 1.8.4.

## 4.5.24 — 2026-08-24

- Met à jour la roadmap publique avec Core 4.5.24, Hub 4.5.11 et CallTracker 1.9.1.
- Officialise la règle UX : aucun bandeau WordPress natif ne doit rester visible dans les écrans AWM CallTracker; les résultats passent par le loader AWM.
- Documente la conservation de l’action native « Annuler » dans le loader lorsque disponible.

---

## 4.5.23 — 2026-08-24

- Corrige globalement les liens de statut WordPress (`Toutes`, compteurs, état actif) sur les écrans AWM en mode sombre, y compris lorsqu’ils sont rendus hors du formulaire de liste.
- Ajoute une tombstone persistante pour tout client WHMCS supprimé localement : les synchronisations clientes et complètes ignorent ensuite cet identifiant jusqu’à autorisation explicite.
- Conserve l’historique métier du client supprimé, révoque ses accès/Connector et permet une restauration contrôlée depuis Utilisateurs.
- Enregistre la route publique Core `callink/v1/recording` pour le callback Twilio d’enregistrement conditionnel.
- Met à jour la roadmap publique avec les versions des huit modules et l’audit transversal 4.5.23.

## 4.5.22 — 2026-08-24

- Ajoute un moteur Core d’actions groupées clients avec aperçu serveur, jeton à usage unique, empreinte d’état, confirmation exacte et journalisation.
- Autorise la désactivation CallTracker en lot, l’archivage protégé et la suppression définitive uniquement des fiches locales vides; les comptes WHMCS actifs et la fiche Alliance interne sont bloqués.
- Révoque sessions et Hub Connector avant archivage/suppression sensible.
- Masque les anciens boutons Light/Dark de modules lorsque le shell Core partagé est actif afin d’éviter les doubles contrôles de thème.
- Roadmap publique alignée sur Core 4.5.22, Hub 4.5.9 et CallTracker 1.8.1.

## 4.5.21 — 2026-08-24

- Met à jour la roadmap publique avec **Core 4.5.21**, **Hub 4.5.8** et **CRM 1.5.1**.
- Officialise la règle de contexte des fiches clients : le module source reste maître de l’interface.
- Conserve toutes les API, permissions, sessions, secrets et routes métier existantes.

---

## 4.5.20 — 2026-08-24

- Met à jour la roadmap publique pour **Hub Client AWM 1.8.2**.
- Documente la correction de taille/alignement de l’icône **Hub** dans le menu WordPress client.
- Aucun changement des API métier, de la facturation, des sessions ou de CallTracker.

---

## 4.5.19 — 2026-08-24

- Corrige le calcul de facturation du Hub afin que les factures **Payées, Annulées, Remboursées ou Brouillon** aient toujours un solde payable de 0 $.
- Le résumé **Solde à payer / Factures à payer / En retard / Payées** est maintenant calculé sur **toutes** les factures WHMCS du client grâce à une pagination complète, et non seulement sur le premier lot de 25/50 résultats.
- Une facture n'est comptée en retard que si elle est réellement payable et que son statut ou son échéance le justifie.
- Le numéro WHMCS interne est utilisé comme repli lorsque `invoicenum` est vide, afin d'éviter l'affichage « Facture WHMCS # » sans numéro.
- Aucun changement à CallTracker, CRM, Hub AWM ou Hub côté client.

---

## 4.5.18 — 2026-08-24

- Décorrèle la facturation du compte Alliance de l’activation du module `crm_awm` côté client.
- Les routes `/client/invoices` et `/client/invoice-payment` exigent toujours une session client valide et conservent le contrôle de propriété WHMCS, mais ne requièrent plus un service CRM client.
- Identifie la réponse de facturation comme `account_billing` afin de distinguer la facturation Alliance d’un futur CRM que le client pourrait activer pour ses propres clients.
- Met à jour la roadmap publique avec Core 4.5.18 et Hub Client 1.8.1.

---

## 4.5.16 — 2026-08-24

- Enregistre dans Core les routes publiques/signées des MP3 CallTracker et les routes client de routage/audio.
- Sert les MP3 CallTracker sans exposer leur chemin de stockage et avec validation du jeton de campagne.
- Conserve la validation client/campagne deny-by-default pour les modifications du numéro de réception et du Message 2.
- Affiche maintenant les **Notes de version** dans la Publication active de Core → Mises à jour.
- Ajoute un **Historique des versions** pour les dix publications conservées par le registre central.
- Met à jour la roadmap publique avec Core 4.5.16, Hub 4.5.7, CallTracker 1.8.0 et Hub Client 1.7.0.

---

## 4.5.15 — 2026-08-24

- Corrige le footer WordPress qui restait blanc en mode sombre sur les pages AWM.
- Le fond, le texte, les liens et la bordure du footer héritent maintenant des variables clair/sombre du shell AWM.
- Dans le déploiement distant, les modules serveur absents du WordPress client sont libellés **Hébergé chez Alliance** au lieu d’un tiret ambigu.
- Aucun changement de données, route publique, permission, CallTracker ou Hub Client.

# Changelog

## 4.5.50 — 2026-08-27
- Ajoute un contexte visuel Studio au shell administratif partagé.
- Studio possède désormais son accent, son icône et son en-tête propres au lieu d'hériter du contexte Hub.
- Le mode sombre/clair Studio suit exactement les réglages globaux Alliance.


## 4.5.14 — 2026-08-24
- Corrige le premier test reel du deploiement distant : Core rafraichit l inventaire avant de creer la file.
- Ne deploie plus les huit paquets d une Suite aveuglement : seulement les modules installes dont la version publiee est superieure.
- Affiche clairement A jour lorsqu une Suite plus recente ne contient aucun nouveau paquet pour le site client.
- Publie Hub Client 1.6.1 comme premiere mise a jour testable depuis un site 1.6.0.
 — Core AWM

## 4.5.13 — 2026-08-24

- Corrige les contrastes du tableau de bord Core en mode sombre : titres de cartes, descriptions, métadonnées et composants héritent maintenant des couleurs globales définies dans Hub AWM.
- Corrige **Core AWM → Mises à jour** : cartes, tableaux, inventaires et textes utilisent les mêmes surfaces clair/sombre que le shell AWM au lieu de couleurs WordPress fixes.
- Ajoute **Utilisateurs** et **Mises à jour** dans la navigation principale en pastilles de Core pour correspondre aux sous-menus déjà disponibles.
- Le correctif est strictement visuel/navigationnel : aucune table, option, route publique, permission, donnée métier ou logique de migration CallTracker n'est modifiée.

---
## Historique conservé

## 4.5.12 — 2026-08-24

- Ajoute **Core AWM → Mises à jour** comme registre central de distribution de la Suite AWM.
- Un seul fichier `suite-awm-modulaire-X.Y.Z.zip` peut être analysé et publié; Core extrait les ZIP de modules, vérifie leurs structures et versions, refuse toute diminution de version et calcule un SHA-256 par paquet.
- Ajoute les canaux **Stable/Bêta**, la suspension d’une publication active et un stockage privé configurable via `AWM_UPDATE_STORAGE_PATH`.
- Ajoute l’installation séquentielle des modules présents sur le WordPress Alliance avec **barre de progression**, sauvegarde préalable et rollback; Core est installé en dernier.
- Ajoute le déploiement distant vers les sites Hub Client autorisés, sans FTP/SSH : commande signée par le secret du Connector, téléchargement HTTPS depuis Alliance, vérification SHA-256 puis installation locale via les API WordPress.
- Ajoute inventaire des versions par site, état par module, arrêt du déploiement après deux erreurs et rollback distant.
- Ajoute les routes Connector `/client/updates/inventory`, `/client/updates/check` et `/client/updates/report`; toutes les routes publiques restent enregistrées dans Core.
- Le premier passage à Hub Client 1.6.0 demeure un bootstrap manuel sur les sites déjà en 1.5.0; les mises à jour suivantes deviennent pilotables depuis Core.
- Maintient CallTracker AWM 1.7.0 inchangé afin de ne pas introduire de risque dans la migration urgente.

---
## Historique conservé

## 4.5.11 — 2026-08-24

- Ajoute la synchronisation et le scan sécurisé des utilisateurs WordPress d’un site Hub Client lié.
- Ajoute une liste d’autorisations locale par fiche client; les sessions `site_admin_delegate` sont désormais refusées par défaut si la référence WordPress locale n’est pas approuvée.
- Stocke le secret de scan dans le coffre cryptographique Core et limite le scan au domaine réellement associé au Connector.
- Révoque les sessions clientes lorsqu’une autorisation locale est retirée ou qu’un compte autorisé disparaît du scan.
- Journalise synchronisation, scan, refus et changement d’autorisation sans stocker de secret.
- Maintient toutes les routes et métadonnées historiques existantes et laisse CallTracker 1.7.0 inchangé.

---
## Historique conservé

# Changelog

## 4.5.50 — 2026-08-27
- Ajoute un contexte visuel Studio au shell administratif partagé.
- Studio possède désormais son accent, son icône et son en-tête propres au lieu d'hériter du contexte Hub.
- Le mode sombre/clair Studio suit exactement les réglages globaux Alliance.
 — Core AWM

## 4.5.10 — 2026-08-23

- Renforce le contrat modulaire du Hub Client : les routes clientes CallTracker (résumé, campagnes, leads, appels et CPL) exigent désormais que le service CallTracker soit activé pour le client.
- Le refus reste côté Core même si une ancienne URL du portail est appelée directement.
- La roadmap publique passe Core à 4.5.10 et Hub Client à 1.4.0 tout en maintenant la version de chacun des huit modules.
- Documente le nouveau portail Hub Client modulaire et responsive sans déplacer les données métier hors de CallTracker/Stats.

---
## Historique conservé

## 4.5.9 — 2026-08-23

- Ajoute les routes Core authentifiées `POST /client/profile` et `POST /client/appearance`.
- Le profil personnalisable conserve le nom canonique CRM/WHMCS et stocke seulement un nom affiché et une fonction propres au Hub Client.
- L’apparence client réutilise le moteur de styles Hub, valide les couleurs, limite les polices à une liste sûre et interdit tout CSS arbitraire.
- Les écritures sont limitées au client porté par la session API, journalisées dans le journal Core et renvoient immédiatement le profil effectif.
- La roadmap publique maintient explicitement les versions de Core, Hub, CRM, CallTracker, Stats, Assistant, Soutien et Hub Client, même lorsqu’un module n’est pas actif sur la plateforme centrale.
- Ajoute Hub Client AWM comme huitième module distinct dans la roadmap publique.
- Aucun identifiant historique, option, route existante, table ou méta n’est supprimé ou renommé.
---
## Historique des versions précédentes

# Changelog

## 4.5.50 — 2026-08-27
- Ajoute un contexte visuel Studio au shell administratif partagé.
- Studio possède désormais son accent, son icône et son en-tête propres au lieu d'hériter du contexte Hub.
- Le mode sombre/clair Studio suit exactement les réglages globaux Alliance.
 — Core AWM

## 4.5.7 — 2026-08-19

- Roadmap publique et changelog système actualisés pour les actions groupées CallTracker 1.6.0 et leur interface Hub 4.5.3.
- Documentation du contrat de sécurité : niveau **Approuver**, nonce, aperçu serveur, confirmation, jeton à usage unique revendiqué atomiquement, état revalidé, verrouillage concurrent et journalisation par élément.
- Confirmation que les nouveaux points d’entrée de lot sont des actions AJAX administratives; aucune API REST publique n’est enregistrée hors Core.
- Les échecs de persistance de l’exclusion anti-réimportation, de l’état local après libération Twilio, du nettoyage d’une réservation et de la propagation historique sont remontés dans le journal central.
- Les écritures partagées de réservations, exclusions legacy et instantanés de suppression sont sérialisées dans CallTracker afin d’éviter la perte d’une mise à jour concurrente.
- Conservation des descriptions explicites de roadmap au lieu de les remplacer par une description générique indexée.
- Aucune table, option, route, constante ou capacité historique supprimée ou renommée.

---

## 4.5.6 — 2026-08-19
- Le type technique `callink_campaign` est explicitement non public, non requêtable côté public, absent de REST/navigation.
- Les libellés WordPress utilisent maintenant Campagne au lieu d’Article dans l’éditeur natif.
- Le statut `publish` historique est conservé uniquement comme état interne de compatibilité pour ne casser aucune requête existante.

## 4.5.5 — 2026-08-19
- Roadmap publique mise à jour pour marquer l’inventaire CallTracker Libre/Réservé/Attribué/À vérifier comme livré.
- Journal de sécurité Core reçoit les événements de réservation et de retrait de réservation de numéros Twilio sans conserver les secrets Twilio.
- Aucun point d’entrée REST supplémentaire n’est ajouté hors de Core; les routes historiques restent inchangées.

## 4.5.4 — 2026-08-18
- Core centralise une résolution canonique des identités clientes afin que l’API Hub agrège les anciennes références sûres d’un même client sans accepter de correspondance par domaine seul.
- Les routes client Campagnes, Appels, Leads et statistiques utilisent désormais les identifiants canoniques et alias historiques sûrs (WHMCS, fusion, courriel exact, téléphone exact ou domaine d’entreprise + identité concordante).
- Le jeton Dialer client n’est délivré que si CallTracker est activé et qu’au moins une campagne active avec Dialer et numéro Twilio est réellement disponible.
- Aucun jeton Alliance n’est exposé au navigateur par ce changement; l’API reste refus-par-défaut et limitée au client porté par la session.

## 4.5.3 — 2026-08-18
- Corrige l’authentification du Hub Client : les administrateurs Alliance peuvent ouvrir un portail client avec une session déléguée strictement limitée à la fiche liée.
- Ajoute une autorisation runtime Hub Connector distincte du code de pairing : secret aléatoire retourné une seule fois, hashé dans Core et révocable.
- Ajoute l’accès délégué des administrateurs WordPress du site client via le Connector, sans transmettre leur mot de passe local à Alliance.
- Les codes de pairing deviennent à usage unique; une régénération révoque l’autorisation runtime précédente.

## 4.5.2 — 2026-08-18

- Suppression de la marge supérieure résiduelle du shell Core AWM afin de l’aligner verticalement sur les autres modules.
- Le fond WordPress `#wpbody` de Core utilise explicitement la surface de page AWM, supprimant la bande claire visible au-dessus du shell en mode sombre.
- Correctif CSS strictement limité au contexte `awm-module-core`; aucun changement d’espacement dans Hub, CRM, CallTracker, Stats, Assistant ou Soutien.
- Aucun changement de route, table, option, permission, API ou donnée.

## 4.5.1 — 2026-08-18

- Le shell Core utilise le logo Alliance officiel lorsque Hub n’a pas de logo personnalisé.
- Core reste visuellement harmonisé mais ne possède aucun réglage d’apparence : il consomme les réglages centralisés dans Hub AWM.
- La façade historique des modules clients délègue à Hub AWM sans retirer les métadonnées ni identifiants historiques.
- Le double en-tête du tableau de bord Core est supprimé lorsque le shell partagé est actif.
- Les panneaux internes de Core héritent maintenant des surfaces, bordures et textes clair/sombre du shell AWM; l’ancien choix de thème `callink-admin-theme` reste lu et synchronisé pour compatibilité.

## 4.5.0 — 2026-08-18

- Core AWM 4.5.0 centralise le shell visuel partagé de toute l’administration AWM : logo Alliance + icône de module, navigation principale en pastilles, sous-navigation cohérente, composants clair/sombre et responsive. Aucun écran métier ni route historique n’est déplacé; Core fournit seulement le contrat visuel commun.

## Interface sécurité 4.4.1 — 2026-08-17

- L’écran Core AWM > Sécurité adopte la charte visuelle AWM avec une organisation par sous-onglets.
- L’accès clients dispose maintenant des filtres Tous / Approuvés / Non approuvés et d’une recherche instantanée par nom, courriel ou ID.
- Les compteurs d’approbation, états visuels, actions Approuver/Révoquer et affichage responsive ont été harmonisés sans modifier le modèle de sécurité deny-by-default.
- Les fonctions existantes de coffre, journal, permissions et compatibilité sont regroupées dans des sections dédiées sans changement de route ni de donnée historique.


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

- Core AWM 4.4.0 ajoute le coffre cryptographique central, une politique deny-by-default avec approbation explicite des clients, la révocation immédiate des sessions/connecteurs, le chiffrement du contexte du journal et la migration des secrets connus.
# Changelog

## 4.5.50 — 2026-08-27
- Ajoute un contexte visuel Studio au shell administratif partagé.
- Studio possède désormais son accent, son icône et son en-tête propres au lieu d'hériter du contexte Hub.
- Le mode sombre/clair Studio suit exactement les réglages globaux Alliance.
 — Core AWM

## 4.3.9 — 2026-08-17
- Core devient l’unique propriétaire des points d’entrée REST/webhooks de la suite : API client, Hub Connector, Twilio CallTracker et collecte Stats AWM.
- Ajout d’un routeur API Core qui conserve les routes historiques `callink/v1` et délègue le traitement métier aux modules actifs sans déplacer leurs données.
- Génération, état et révocation des codes Hub Connector déplacés dans `CallLink_Client_API`; Hub n’écrit plus directement les métadonnées de sécurité du Connector.
- Les routes Twilio et Stats ne sont plus enregistrées par leurs modules; Core les expose et retourne une erreur 503 contrôlée si le module requis est absent.
- Aucun nom de route historique, option, table ou métadonnée n’est supprimé.

## 4.3.8 — 2026-08-17
- Roadmap publique Hub mise à jour pour officialiser le nouveau module Hub Client AWM installable sur le site WordPress du client.
- Le portail déporté `/hub/` utilise l’API client existante et n’expose aucun outil d’administration Alliance sur le site client.
- Aucune route, table, option ni permission historique modifiée par ce lot.

## 4.3.7 — 2026-08-17
- Roadmap publique CallTracker mise à jour avec la protection anti-résurrection des campagnes supprimées lors des synchronisations legacy.


## 4.3.6 — 2026-08-17
- Le rapprochement global Clients ↔ WHMCS sait maintenant dériver un domaine d’entreprise depuis les courriels lorsque le site Web n’est pas renseigné.
- Les domaines de messagerie grand public sont exclus du signal de rapprochement afin d’éviter les associations erronées.
- Les règles de fusion automatique restent conservatrices : les cas domaine + nom restent à vérifier tant qu’un second identifiant fort ne confirme pas la destination.


## 4.3.5 — 2026-08-17
- Ajout d’un rapprochement global des anciennes fiches CallTracker vers les fiches WHMCS canoniques, avec analyse de toutes les correspondances et traitement en lot des cas sûrs.
- Les rapprochements sûrs exigent un identifiant fort et une destination unique; les cas ambigus restent à vérifier manuellement.
- Le transfert global conserve campagnes, appels, formulaires, statistiques, profils et historique, puis archive l’ancienne fiche sans suppression.
- Toutes les destinations WHMCS, actives ou inactives, sont disponibles pour le rapprochement manuel avec leur état visible.
- Chaque fusion globale ou manuelle est journalisée dans le journal central de sécurité.
- Roadmap publique CallTracker/CRM corrigée pour refléter le rapprochement global et le correctif réel de l’écran Campagnes.
- Aucune route, table, option ou capacité historique supprimée.

## 4.3.4 — 2026-08-17
- Roadmap publique mise à jour pour le lot CallTracker : campagnes visibles par client, activité appels/formulaires et harmonisation visuelle.


## 4.3.3 — 2026-08-17

- Roadmap publique actualisée avec l’activation CallTracker par client et le rattachement direct des campagnes.
- Le statut CallTracker est explicitement distinct du statut commercial WHMCS.
- Aucun changement de table, route, option ou capacité historique.


## 4.3.2 — 2026-08-17

- Roadmap publique actualisée pour marquer comme livré l’accès Clients directement dans CallTracker AWM.
- Conservation intégrale de la neutralisation des notices WordPress/tiers introduite en 4.3.1.
- Aucun changement de table, option, route ou capacité historique.

## 4.3.1 — 2026-08-17

- Neutralisation centralisée des bandeaux WordPress et des notices d’extensions tierces sur toutes les pages d’administration AWM.
- Couverture des écrans Core, Hub, CRM, CallTracker, Stats, Assistant, Soutien ainsi que des types `callink_campaign` et `callink_call`.
- Conservation des confirmations et erreurs AWM rendues dans le contenu du module afin de ne pas masquer le résultat d’une action utilisateur.
- Repli CSS limité aux notices globales situées directement dans `#wpbody-content`, sans modifier les messages internes des interfaces AWM.

## 4.3.0 — 2026-08-17

- Matrice de rôles par module avec niveaux Consulter, Modifier, Approuver et Administrer.
- Migration additive des droits historiques des rôles et des utilisateurs sans retrait de capacité.
- Rôles clients et administrateur protégés, avec réparation contrôlée des droits fondamentaux.
- Journal de sécurité centralisé, filtrable et exportable avec rétention configurable et nettoyage WP-Cron.
- Expurgation des secrets, masquage et hachage des adresses IP, identifiant de requête et protection CSV.
- Inventaire des sessions API actives avec révocation individuelle ou par utilisateur.
- Diagnostic des API, webhooks, connexions externes et tâches planifiées.
- Journalisation centralisée des signatures Twilio refusées, collectes Stats rejetées, échecs de tâches et changements de connecteurs.
- Contrat de permissions 1.0 adopté par les sept modules.
- Vérification additive confirmant qu’aucune route, table, option, métadonnée, action ou filtre historique n’a été retiré.

## 4.2.0 — 2026-08-15

- Contrat de version 4.2.0 partagé avec Hub AWM.
- Recherche administrative transversale locale sans transmission à un service externe.
- Clients inactifs exclus par défaut des résultats.
- Roadmap Hub actualisée avec la recherche transversale livrée.

## 4.1.3 — 2026-08-15

- Conversations Assistant AWM regroupées en une seule unité de révision.
- Analyse du fil complet avec reformulation des vraies questions et exclusion des messages sans valeur documentaire.
- Réanalyse guidée, réponses éditables et approbation sélective de plusieurs connaissances.
- Historique des analyses et migration automatique des anciennes questions isolées.
- Roadmap enrichie et règle d’accélération par gains rapides compatibles.

## 4.1.2 — 2026-08-15

- Approbation groupée des pages Web explorées vers la base de connaissances.
- Suppression définitive de plusieurs pages sélectionnées avec confirmation préalable.
- Sélection globale, compteur et résultat détaillé de l’opération.
- Contrôles de permission, nonce, type de contenu et état en attente appliqués à chaque page.

## 4.1.1 — 2026-08-15

- Types internes de la mémoire Assistant ramenés sous la limite WordPress de 20 caractères.
- Migration automatique des éventuelles connaissances et conversations enregistrées sous un identifiant tronqué.
- Erreur détaillée conservée lorsque WordPress refuse l’enregistrement d’une connaissance.
- Les modifications manuelles faites dans l’analyse sont utilisées comme version officielle approuvée.

## 4.1.0 — 2026-08-15

- Contrat Core AWM / Hub AWM harmonisé en version 4.1.0.
- CRM AWM reconnu comme module indépendant dans le registre, la santé du système et la roadmap.
- Roadmap enrichie avec une description de résultat pour les dix améliorations de chacun des sept modules.
- Suggestions approuvées publiées avec leur description et limitées à cinq ajouts par module.
- Actualisation sécurisée du fil WHMCS d’un ticket depuis Core AWM, même lorsque seule sa référence publique est connue.
- Compatibilité des identifiants, tables et données historiques maintenue.

## 4.0.0 — 2026-08-15

- Séparation réelle de Core AWM et Hub AWM en deux extensions.
- Core limité à la sécurité, aux rôles, permissions, API, utilisateurs, connexions et modules.
- Nouveau menu WordPress Core AWM avec Sécurité, API et connexions, Utilisateurs et Modules.
- Conservation du dossier technique `awm-hub-core`, des constantes, tables, options et routes historiques.
- Hub AWM devient une dépendance distincte pour tous les écrans et rendus visuels.
- Contrat de roadmap commun permettant de présenter une analyse et un plan futur par module.

## 4.5.17 — 2026-08-24
- Ajout des routes client Factures et Paiement, enregistrées dans Core.
- Validation stricte de la propriété WHMCS avant exposition d’une facture ou génération d’un paiement.
- Création de SSO WHMCS à usage unique pour ouvrir la facture payable sans exposer les identifiants WHMCS.
- Aucune donnée de carte ou CVV ne transite ou n’est stockée dans AWM.
## 4.5.319 — 2026-10-21
- Autorité Light/Dark unifiée sur les routes legacy Hub Clients; synchronisation html/body/datasets et correction de la priorité Light/Dark.



---

## README.md

# Core AWM 4.5.328

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

Core 4.5.328 consigne le contrat d’identité de l’en-tête et ajoute favicon_url au payload utilisateur authentifié, depuis le favicon choisi ou détecté dans l’identité canonique du client. La mémoire reçoit une décision, avec 144 entrées antérieures conservées. Permissions, sessions, coffre, catalogue et compilateur restent sous leurs contrats existants.

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.

---

# Core AWM 4.5.327

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

Publie les recettes de prévisualisation canoniques et ajoute dans Design System & QA le parcours URL → brouillon → aperçu clair/sombre → approbation explicite → application comme défaut client. Les actions utilisent les permissions Core/CRM et des nonces; aucun modèle n’est approuvé automatiquement. Le registre conserve des configurations contrôlées et leur empreinte; la bibliothèque réutilise ou télécharge les fichiers de police manquants, avec variantes et origine. La mémoire ajoute deux décisions en conservant les 142 règles précédentes.

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 4.5.326

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

Le contrat d’apparence valide les deux profils avant toute écriture. Une bascule seule enregistre uniquement le choix Auto/clair/sombre et préserve les profils et l’identité automatique. Le raccordement administratif applique les variables et les classes du profil correspondant au mode Core. La mémoire consigne la décision et conserve les 141 entrées antérieures.

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.

---

# Core AWM 4.5.325

L’utilisateur a accepté la Suite **4.5.466** comme référence d’apparence puis demandé l’inscription de cette décision dans la mémoire Core, les journaux et les roadmaps. La décision `AWM-APPEARANCE-BASELINE-466-001` est ajoutée au seed `2026-10-22.4`; les 139 entrées antérieures restent identiques.

Les cartes et fiches administratives CRM et Hub conservent les couleurs et les six axes du client, avec la variante claire/sombre du Core de l’opérateur. Hub Client conserve indépendamment **Automatique · logo puis site**, **Toujours sombre** ou **Toujours clair**. La personnalisation manuelle reste prioritaire sur la réanalyse; l’affichage administratif n’écrit aucun choix client.

Le lot officiel de migration mémoire de 4.5.466 garde son identifiant immuable `2026-10-22.3`, distinct de la version du seed courant. Un site qui passe directement de 4.5.465 à cette version peut donc encore appliquer ses révisions officielles bornées, avec les mêmes empreintes autorisées et protections des révisions humaines. La nouvelle décision est insérée par le mécanisme de mémoire existant et ses événements de journalisation habituels.

La création de styles depuis une URL dans **Core → Design System & QA** reste proposée et différée. L’acceptation de la livraison ne constitue ni une installation sur l’hébergement ni une validation en production. Les résultats locaux de cette Suite sont documentés dans son rapport de validation.

## Accès au Hub Client depuis la fiche CRM

La décision `AWM-CRM-HUB-SITE-USERS-001` précise le bloc permanent **Hub Client & connexion** rendu par Hub 4.5.110 dans la fiche CRM. Quand le site principal est lié par un Connector runtime autorisé, ses comptes WordPress apparaissent avec leurs cases de sélection. Le scan et l’enregistrement utilisent l’annuaire et l’allowlist existants de Core, avec leurs permissions, le nonce CRM et le périmètre explicite du site principal. Un simple affichage ou scan n’accorde aucun accès. Les références invalides et les sélections fondées sur un annuaire périmé sont refusées. Les cases utilisent les références stables Core; une modification réelle des droits réutilise la révocation des sessions API du site concerné et les journaux Core existants.

Le raccourci **Hub Client** ouvre le portail du site appairé dans un nouvel onglet, en conservant le sous-dossier WordPress et l’authentification ou la session existante. Il ne crée pas de nouveau SSO. Les deux nouvelles décisions portent la mémoire à **141 clés uniques**, sans modifier les 139 entrées de 4.5.466. Core reste l’autorité des droits et du transport; cette interface est fournie par Hub.

---

# Core AWM 4.5.324

Core choisit la variante claire ou sombre des cartes et fiches administratives explicitement marquées, en conservant leurs couleurs et leurs six axes client. La synchronisation se fait dès le rendu et lors des bascules, sans écriture de préférence client. Les règles du shell respectent ces zones personnalisées. Les règles officielles de mémoire concernées évoluent par révisions bornées et vérifiées; les révisions humaines sont préservées.

## 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 4.5.323 — 2026-10-22 · Suite 4.5.464

La décision de 4.5.463 qui imposait le profil Core au contenu CRM était notre interprétation erronée, et non une demande de l’utilisateur. L’instruction explicite du 22 octobre 2026 la remplace : le contenu de la fiche doit utiliser le profil personnalisé commun à Hub Client. Les anciennes entrées ci-dessous sont conservées comme historique et sont remplacées sur ce point par la présente décision.

Core rend publique `CallLink_Client_API::style_payload(WP_User)` avec son corps canonique conservé. CRM peut ainsi lire le contenu de profil déjà partagé avec Hub Client, sans nouvel endpoint. Les deux feuilles administratives Core excluent le nouveau scope CRM et ses descendants au même niveau que la fiche Hub déjà protégée, sans augmenter la spécificité des règles ailleurs.

Le bandeau d’identité du client et le contenu de sa fiche sont deux zones `.callink-crm-client-themed`. Le header global, les guides, le retour et le passage vers Hub restent dans le thème administratif Core. Le mode clair/sombre de la fiche est celui du client, résolu depuis logo/site ou choisi manuellement. Il est indépendant du mode Core; la palette reste également celle du client.

Les synchronisations globales Core/Hub respectent `data-client-color-scheme` : elles ne remplacent plus l’apparence locale par celle du shell. Les cartes et la fiche Hub utilisent l’accent du profil choisi, par exemple Rouge, et la variante claire/sombre du client.

La mémoire, l’architecture et la revue Futur passent à `2026-10-22.1`, avec **139 clés uniques**. La clé historique `AWM-CRM-ADMIN-DESIGN-COMPOSER-001` est corrigée sur place afin de remplacer la règle contradictoire dans une mémoire déjà importée. Le rafraîchissement documentaire normal ne migre aucune donnée métier.

Le profil automatique choisit une combinaison existante du catalogue à partir de l’identité du client : l’exemple demandé est **Arctic + Rouge pour un logo rouge**. Le même profil est consommé par Hub Client et la fiche CRM; il ne s’agit pas de reconstruire le CSS du site. La couleur et l’apparence privilégient le logo exploitable, puis le site, avec leurs replis documentés; les autres axes utilisent les indices CSS du site disponibles.

L’automatique est un point de départ : le client peut toujours personnaliser son thème. Les choix manuels existants restent prioritaires; une réanalyse ne les remplace pas. Le retour à l’automatique reste une action explicite disponible dans l’interface.

**Évolution proposée et différée — Création de styles depuis une URL dans Design System & QA**. Dans Core AWM → Design System & QA, saisir l’URL d’un site, analyser son identité visuelle et sa structure, puis proposer de nouveaux styles sous forme de tokens contrôlés. Prévisualiser chaque proposition en Light/Dark, ajuster ses paramètres, la nommer puis l’enregistrer au catalogue pour les clients après validation explicite. Évolution proposée et différée; aucune génération, activation ou publication de style n’est ajoutée dans 4.5.464. Cette piste ajoute la saisie d’une URL et la proposition de nouveaux jeux de tokens; elle complète l’éditeur de presets contrôlés, les favoris et les prévisualisations déjà prévus sans les recompter.

Les résultats effectivement acquis sont consignés dans les rapports de validation de la Suite 4.5.464. Aucun résultat de 4.5.463 ne vaut validation de cette nouvelle version. La validation sur l’hébergement actuel et la publication publique ne sont pas présumées.

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 4.5.322 — 2026-10-21 · Suite 4.5.463

Le dossier client CRM est une surface administrative centrale : il utilise le profil Design Composer sélectionné dans Core. Les cartes et la fiche personnalisée de Hub AWM conservent leur exception explicite dans `.callink-client-detail-themed`; la présence de `client_id` dans une route CRM ne crée pas une autre exception.

Cette version actualise la mémoire, l’architecture et la revue Futur en `2026-10-21.16`, avec **139 règles uniques**. La nouvelle règle `AWM-CRM-ADMIN-DESIGN-COMPOSER-001` fixe le chargement réel du CSS CRM et la consommation des tokens administratifs. Les règles de frontière et de parité Hub sont précisées, sans modifier Hub 4.5.107 ni Hub Client 1.14.39.

Le retour vidéo sur `callink-crm&tab=clients&client_id=<id>` montre des fonds bleus/violets hérités sous Core Cyan Dark. Le correctif visuel appartient à CRM 1.6.35 : chargement de sa feuille dédiée sur la route canonique et adaptation locale des composants aux tokens Core. Core conserve son rôle de fournisseur du profil administratif.

Les contrôles locaux ont été exécutés avec succès et sont consignés dans le rapport de la Suite. Une validation locale ne constitue pas une installation ou une validation sur l’hébergement actuel. Le rafraîchissement normal de la mémoire Core ne migre aucune donnée métier.

## Mise à jour 4.5.321 — 2026-10-21 · Suite 4.5.462

Cette candidate complète le correctif 4.5.461 : le shell administratif conserve son profil et sa frontière CSS, tandis que la fiche doit recevoir le profil Design Composer complet de la carte client. La 4.5.461 isolait la fiche mais ne suffisait pas à compiler et appliquer ses six axes visuels.

Le défaut du haut de page venait notamment du chargement des styles : `module_from_request()` excluait `awm-hub-clients` parce que son nom contient `hub-client`, avant son classement comme route administrative centrale. Le contexte Core devenait vide et les styles du shell et des guides n’étaient pas chargés dans la fiche; le secours précédent ne couvrait que la liste. La route centrale est désormais reconnue exactement avant l’exclusion du véritable portail Hub Client.

Core reste l’autorité du catalogue et des tokens. Le haut du shell conserve son profil administratif; la fiche reçoit celui du client. La nouvelle règle `AWM-HUB-CLIENT-PROFILE-PARITY-001` impose la parité famille, couleurs, typographie, surface, mouvement et densité entre carte et fiche. Mémoire, architecture et revue Futur passent à `2026-10-21.15`.

Les résultats locaux effectivement exécutés sont consignés dans les journaux de la Suite. Le rendu WordPress terrain et la publication 4.5.462 restent à confirmer après installation. Le rafraîchissement documentaire de Core ne modifie aucune donnée métier.

## Mise à jour 4.5.320 — 2026-10-21 · Suite 4.5.461

Core conserve le thème administratif actif tout en isolant la fiche client du Hub. Les règles de surface, texte, champ, géométrie et police des deux CSS administratifs excluent désormais `.callink-client-detail-themed` et ses descendants, avec un filtre de spécificité nulle. Les anciennes règles qui remplaçaient les variables `--client-*` par les tokens du shell sont retirées.

Le header Core, les marqueurs de thème `html/body`, le Design Composer et les guides restent actifs. La liste Clients suit toujours le thème principal et ses cartes gardent leurs tokens `--card-*`. La mémoire clarifie les exceptions de carte/fiche et les familles visuelles déjà approuvées; mémoire, architecture et revue Futur passent à `2026-10-21.14`.

Cette mise à jour cible le rendu et les métadonnées documentaires Core. Les données métier ne changent pas. La validation WordPress sur le site utilisateur reste à effectuer après installation; consulter les journaux de la Suite pour les résultats locaux effectivement exécutés.

## 4.5.316 — Autorité du thème principal sur Hub Clients

Core verrouille la liste `Hub AWM > Clients` sur les tokens Design Composer de l administrateur. Les cartes client restent volontairement hors neutralisation afin de prévisualiser leur thème propre.


## Mise à jour 4.5.315 — 2026-10-21
- Publie le catalogue Design Composer comme contrat partageable pour Hub AWM et Hub Client.
- Le payload Hub Client expose catalogue, tokens compilés, source et libellé de source du thème.
- Le retour au thème automatique relance réellement la détection `logo -> site Web -> thème AWM`.
- Hub AWM > Clients conserve le shell administratif central tandis que les cartes clients peuvent prévisualiser leur profil propre.
- Ajoute les règles de mémoire sur auto-identité, propagation du catalogue, scope de thème des services client et cartes de prévisualisation.

## Core AWM 4.5.314 - Loader entierement harmonise
Le backdrop reste volontairement discret, mais la carte du message suit maintenant la vraie surface du Design Composer : couleur/surface, bordure, texte, rayon et ombre. Un theme orange ne retombe donc plus sur une carte bleu marine.

## Core AWM 4.5.313 - Backdrop theme subtil
Le loader conserve maintenant la teinte du Design Composer sans dominer l ecran. La reference redevient la sensation historique du loader : voile neutre leger, blur 3px, carte centrale neutre; l accent n est qu une teinte discrete (8 % Light, 12 % Dark).

## Core AWM 4.5.312 - Roadmap source coverage + overlay accentué
Le Design Composer conserve ses axes indépendants mais Surface et Mouvement deviennent beaucoup plus expressifs et testables. Chaque axe propose désormais 12 choix significatifs. Le laboratoire affiche un aperçu dédié, et les règles finales ont une priorité suffisante pour ne plus être masquées par des CSS legacy. `prefers-reduced-motion` reste prioritaire.

## Core AWM 4.5.310 - Design Composer pour le Web
Core expose maintenant un compilateur `website_tokens()` qui transforme un profil Design Composer en tokens neutres destinés à Studio : couleurs, géométrie, typographie, surface, mouvement et rythme de layout. Core reste l autorité du langage visuel; Studio possède la construction des pages et Hub Client applique les tokens au niveau de la page. Aucun kit global Elementor existant n est modifié automatiquement.

## Core AWM 4.5.308 - Design System dynamique
Core compose maintenant le rendu administratif avec quatre axes independants : famille visuelle, couleur, Light/Dark et densite. Les combinaisons sont generees a partir de tokens controles afin d eviter le CSS arbitraire et de conserver contraste, geometrie et etats interactifs coherents.

## Core AWM 4.5.307 - Table de référence Dark complète

Cette version termine le correctif Dark du tableau de référence de `Design System & QA`. Le fond clair natif de WordPress (`widefat striped`) est neutralisé non seulement au hover mais aussi au repos, sur les lignes impaires/paires, les cellules, le focus et l'état selected. Tous ces états utilisent désormais les tokens du preset actif. Hub Client reste hors du Design System administratif central.

## Core AWM 4.5.306 - Version source cohérente

Core 4.5.306 corrige une divergence de packaging : le header WordPress `Version:` et la constante runtime `AWM_CORE_VERSION` sont maintenant alignés et contrôlés ensemble par l importeur. Cette garde évite qu un ZIP annonce une version différente de celle utilisée par le runtime ou le manifeste de Suite.

## Core AWM 4.5.305 - Visual QA multi-onglets robuste

Les cartes de la matrice QA ouvrent maintenant leur destination dans un nouvel onglet/fenêtre de façon renforcée : `target=_blank` reste présent et un gestionnaire `window.open` intercepte le clic pour empêcher que la page Design System & QA soit remplacée. Chaque carte affiche aussi clairement `Nouvel onglet`.

## Core AWM 4.5.304 - Visual QA multi-onglets

La matrice de verification de `Design System & QA` conserve maintenant le laboratoire ouvert : chaque route QA s ouvre dans un nouvel onglet/fenetre avec `noopener noreferrer`. Cela facilite les comparaisons Light/Dark et les validations multi-modules sans perdre le contexte QA.

## Core AWM 4.5.303 - Contraste hover Dark

Cette version corrige le dernier retour terrain du Design System : les lignes de tableau en mode Dark ne peuvent plus récupérer le fond clair natif WordPress au survol. Le fond, le texte principal et le texte secondaire du hover sont maintenant imposés par les tokens du preset actif sur les surfaces administratives centrales.


## Core AWM 4.5.302 - Sélecteur de styles et fermeture CSS terrain

Core 4.5.302 rend le changement de preset impossible à manquer : `Design System & QA` affiche maintenant un sélecteur déroulant explicite en plus des cinq cartes d aperçu, et `Affichage` expose le même contrôle. La vidéo terrain a également montré que certains boutons et champs conservaient des arrondis à cause de sélecteurs legacy plus spécifiques. Un contrat final sous `#wpbody-content` impose désormais la géométrie carrée sur toutes les surfaces administratives centrales. Les seuls cercles permis sont les points de statut et les radios lorsqu ils transmettent une information.

La page QA contient maintenant les suggestions de prochaine phase : diff visuel automatisé Light/Dark, lint CSS, grille d espacement, états sémantiques, responsive, WCAG, tableaux standardisés et captures de référence.


## Core AWM 4.5.301 - Cohérence de version Suite

Core 4.5.301 renforce la garde de publication de Suite. Les versions lues dans le ZIP du module, le manifeste racine et `roadmap_sync.versions` sont normalisées puis comparées strictement. En cas de divergence, Core affiche désormais les trois valeurs observées plutôt qu un message générique. Le build de Suite doit exécuter le même triplet de contrôle avant livraison.

Les cinq presets visuels, le laboratoire Design System & QA, la géométrie sans arrondis et la parité Light/Dark de Core 4.5.300 restent inchangés.

## Core AWM 4.5.300 - Design System & QA

Core ajoute un laboratoire de styles administratifs. Cinq presets peuvent être changés instantanément depuis Affichage ou depuis la page Design System & QA. Le choix est mémorisé par utilisateur et reste indépendant du thème Light/Dark et des modes Guidé/Standard/Avancé. La page Design System sert aussi de bibliothèque de composants et de matrice de validation visuelle.


## Core AWM 4.5.299 - Sweep final sans arrondis

Core 4.5.299 prolonge le Design System Square Blue avec une passe terrain finale : toutes les surfaces administratives centrales AWM doivent maintenant etre visuellement sans arrondis residuels, en Light comme en Dark. Les cartes, panneaux, champs, onglets, filtres, badges, tableaux et boutons restent alignes sur la meme geometrie carree. Seuls les vrais points de statut et les radios conservent une forme circulaire lorsque cette forme transmet l etat.

## Core AWM 4.5.298 - Square Blue sur toutes les pages et onglets

Core 4.5.298 complete le Design System introduit en 4.5.297. L audit a cible les ecrans qui conservaient des couleurs, surfaces ou themes legacy et impose maintenant une parite Light/Dark sur Core, Hub, CRM, LeadTracker, Stats, Assistant, Soutien, Studio et Tech. Les CSS modules gardent leurs regles de layout, graphiques et composants metier; Core reste l autorite des couleurs, typographies, controles, cartes, tableaux, formulaires et navigations.

Le theme est unique et persistant. Les alias historiques des modules sont synchronises avec le theme Core afin qu une page ne puisse plus afficher simultanement un fond clair et des cartes sombres. Hub Client reste hors de cette couche et son apparence autonome n est pas modifiee.

## Core AWM 4.5.297 - Design System Square Blue

Core devient l autorite visuelle des interfaces d administration AWM centrales. Le fichier `assets/css/awm-admin-design-system.css` fournit les tokens et composants globaux : bleu, surfaces nettes, boutons/cartes carres, formulaires, tableaux et navigations. Il est charge apres les CSS modules pour garantir une apparence coherent. Hub Client est volontairement exclu.

## Core AWM 4.5.296 - CRM externes optionnels
Core expose maintenant un registre neutre de fournisseurs CRM externes, activés client par client. Les clés et secrets demeurent dans Core; Hub ne conserve que l activation. Capturia est le premier fournisseur enregistré et n est pas présenté aux clients qui ne l utilisent pas.

## 2026-10-20 - Core AWM 4.5.295
Cette version ajoute uniquement la regle d architecture Capturia Identity Mapping v2 et met a jour les contrats Memoire/Architecture/Futur. Le Core ne cree aucun contact Capturia et ne modifie aucun lead a l installation.

# Core AWM 4.5.294 — Affichage commun AWM

Suite AWM 4.5.433 introduit un mode d affichage par utilisateur : **Guidé**, **Standard** ou **Avancé**. Le sélecteur est disponible dans l entête partagé AWM. Les parcours guidés, aides contextuelles et options avancées peuvent être activés séparément depuis **Affichage**. Ces réglages sont purement visuels et ne changent jamais les données ni les permissions.

## 2026-10-15 - 4.5.293 / Suite AWM 4.5.415 - loi Capturia automatique + seed Mémoire versionné

- Ajoute la règle critique `AWM-CAPTURIA-AUTO-ALL-FORMS-001` : quand Capturia VMV-NAT est actif, tout formulaire capturé du site principal est routé automatiquement, sauf mapping explicite vers une autre campagne.
- Ajoute `AWM-SUITE-PACKAGING-SAFETY-001` après l incident 4.5.413 : aucun arbre de travail ne doit entrer dans un ZIP Suite publié.
- Corrige le mécanisme de seed : `SEED_VERSION` passe à `2026-10-15.4` afin que les nouvelles lois ajoutées depuis 4.5.411 soient réellement importées dans une base Core déjà initialisée, sans réécrire les règles existantes.
- Architecture et Revue Futur passent à `2026-10-15.4`.

## 2026-10-15 - 4.5.292 / Suite AWM 4.5.413 - loi multi-formulaires Capturia et diagnostic par lead

- Ajoute la regle critique Memoire `AWM-CAPTURIA-FORM-SOURCES-001`: un moteur de formulaire explicitement cable et supporte ne doit jamais etre ignore par le routage Capturia VMV-NAT.
- Memoire AWM embarquee: 104 regles.
- Architecture AWM passe a `2026-10-15.3` et formalise le circuit Elementor / Gravity Forms / Contact Form 7 -> VMV-NAT -> Capturia -> preuve technique LeadTracker.
- Le canal Core `client/forms/capturia-delivery` transporte maintenant source, identifiant du formulaire, phase et curseur de notes, toujours sans PII.
- La regle d heure canonique existante est appliquee au diagnostic LeadTracker: stockage UTC, affichage America/Toronto HAE/HNE.
- Revue Futur `2026-10-15.3`: prochaine nouveaute prioritaire proposee, matrice de sante des sources et alertes recu-sans-preuve.
- Aucun lead, envoi Capturia, migration ou deploiement distant n est execute par Core a l installation.

## 2026-10-15 - 4.5.291 / Suite AWM 4.5.412 - Architecture du pipeline CRM et loi de provenance

- Met à jour **Architecture AWM** vers `2026-10-15.2` : CRM AWM devient explicitement la source de vérité des opportunités et de leur état commercial.
- Ajoute le flux transversal **Interaction CallTracker → opportunité CRM** : création explicite, référence source stable/idempotente, pipeline CRM, issue Gagné/Perdu.
- Ajoute la règle Mémoire `AWM-CRM-OPPORTUNITY-SOURCE-001`; la Mémoire Core contient maintenant 103 règles embarquées.
- Le déplacement d une opportunité ne peut jamais modifier le lead/appel/formulaire source, la campagne, le CPL ni sa qualification opérationnelle.
- La revue Futur `2026-10-15.2` confirme le pipeline CRM 1.6.33 comme vraie nouveauté de cette Suite et conserve les prochaines nouveautés de chacun des dix modules.
- Aucun lead, opportunité, campagne, facture, CPL ou statut n est créé/modifié par Core à l installation.
- Les routes de sous-menu WordPress restent enregistrées conformément à la règle de stabilité 4.5.403.

## 2026-10-15 - 4.5.290 / Suite AWM 4.5.411 - Mémoire, architecture et revue Futur obligatoires

- Ajoute **Core > Outils avancés > Architecture AWM**, un registre en lecture seule et exportable des responsabilités, sources de vérité, frontières de stockage, flux critiques et dépendances de la Suite.
- Ajoute un snapshot **Revue Futur** couvrant les dix modules : maintenance/correctifs, améliorations et vraies nouveautés, recoupé avec la roadmap publique consultée en direct avant le build.
- Ajoute les règles Mémoire `AWM-ARCHITECTURE-SOURCE-001`, `AWM-SUITE-FUTURE-REVIEW-001` et `AWM-CAPTURIA-CRM-PII-001`; le seed passe à `2026-10-15.1` sans réécrire les révisions existantes.
- Les futures publications de Suite, une fois Core 4.5.290 actif, doivent déclarer `architecture_contract` et `future_review` dans leur manifeste, avec couverture des dix modules et URL de roadmap publique Alliance.
- Architecture Capturia clarifiée : Capturia reçoit les données personnelles utiles du prospect VMV-NAT; seule la table de preuve AWM reste PII-free.
- Aucun connecteur, campagne, CPL, prospect, déploiement distant ou migration métier n est lancé par cette version. Seul Core change.

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

- Ajoute le canal Connector authentifié `client/forms/capturia-delivery` pour recevoir du site Vendre Maison Vite une preuve technique PII-free après l envoi d un formulaire VMV-NAT vers Capturia.
- Core vérifie le client, le site appairé et l instance avant de transmettre le reçu à LeadTracker; aucune clé Capturia ni donnée nominative n est incluse dans ce reçu.
- Le canal ne crée ni contact, ni campagne et ne modifie aucun CPL. Les outils et la clé API Capturia restent centralisés dans Core.
- Mémoire de développement : règle `AWM-CAPTURIA-PROOF-ARCHIVE-001` ajoutée; les règles existantes sont conservées.

## 2026-10-15 - 4.5.288 / Suite AWM 4.5.405 - Capturia dans Core

- Ajoute **Capturia - Vendre Maison Vite** dans `Core AWM > Connexions > Coffre et cles`.
- La nouvelle cle API peut etre remplacee directement dans Core, sans trousseau v2 obligatoire pour cette operation; elle reste chiffree au repos par le coffre Core existant.
- Bouton de test en lecture uniquement (`/me`, un contact, une source); aucune ecriture fournisseur durant le test. Les scopes d ecriture sont seulement detectes et affiches.
- La cle n est jamais reaffichee ni journalisee. Capturia reste strictement limite a Vendre Maison Vite.
- La connexion peut ensuite etre promue dans le trousseau v2 lorsque celui-ci est prepare.
- LeadTracker 1.11.56 lit cette cle Core en priorite et conserve l ancienne cle par campagne uniquement comme repli de compatibilite.
- Aucun lead, CPL, source Capturia, campagne ou statut commercial n est modifie lors de l installation.

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

Canal CRM client prive dans Core, sans stockage metier parallele; garde client/site/instance/autorisation et chiffrement Core existant.

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.

---

# Core AWM 4.5.286 - Correctif acces aux pages secondaires

Suite AWM 4.5.403. Base : Core 4.5.285 de la Suite 4.5.402.
Le correctif retablit le parent WordPress des mises a jour, versions, memoire et autres outils secondaires, tout en conservant les cinq rubriques du nouveau menu.

Voir GUIDE-REPARATION-ACCES-MAJ-4.5.403.md pour le secours depuis WordPress, sans remplacer Core par l'installateur natif bloque par Recovery. Toutes les protections existantes restent actives. Les donnees metier et cles ne sont pas migrees par ce correctif.

---

# Suite AWM 4.5.402 / Core AWM 4.5.285
## Core simplifié : navigation, accueil et lisibilité
Date : 14 octobre 2026. Base exacte : Suite AWM 4.5.401.
Statut : candidate validée localement, essai WordPress pilote requis.

La navigation Core est regroupée en cinq espaces : **Accueil**, **Connexions**, **Utilisateurs et accès**, **Modules et mises à jour**, **Outils avancés**. Un seul registre définit le menu, les onglets et la recherche d'outils. Les pages historiques restent enregistrées et conservent leurs autorisations. Les entrées inconnues ajoutées par une autre extension ne sont pas supprimées.

L'accueil propose trois tâches clairement expliquées. L'ancien bilan technique reste accessible sous Outils avancés > Diagnostic complet. Le coffre est sous Connexions > Coffre et clés. Les textes, indicateurs, filtres, boutons et panneaux de Mémoire AWM suivent maintenant les thèmes clair et sombre de Core. Les styles de cette refonte ne sont chargés que sur les pages Core.

**Seul Core change. Les dix autres ZIP de composants sont conservés octet pour octet.** Coffre, trousseau, permissions, API Client, journal de sécurité, moteur de mises à jour et Recovery ne sont pas réécrits. Les formulaires de gestion conservent leurs points d'entrée, nonces et confirmations.

Aucune clé n'est migrée par cette refonte, aucun statut client/campagne n'est basculé, aucun CPL n'est recalculé. Une règle UX est ajoutée au seed de Mémoire AWM (95 règles, version 2026-10-14.2); les 94 entrées précédentes restent identiques. La mécanique existante de chargement du seed s'applique; le schéma de base reste 1.4.

Cette version ne termine pas la migration des connecteurs Capturia/Screpy, le registre CRM des prospects uniques à vie, les lecteurs Stats/CPL ou la séparation du statut commercial. Ces chantiers restent explicites dans la roadmap, sans affichage trompeur de livraison.

Sources de roadmap mises à jour dans le paquet. La page publique n'a pas pu être consultée au cours de la validation et aucune publication en ligne n'est confirmée.

---

## Historique conservé

# Suite AWM 4.5.401 / Core AWM 4.5.284
## Coffre central - première étape, validation terrain requise
Date : 14 octobre 2026. Base : Suite 4.5.400.

Cette version ajoute dans Core un trousseau externe versionné et le stockage central chiffré de trois configurations : Twilio, application Google Ads et session OAuth Google Ads. La migration est explicite, connexion par connexion, après préparation du trousseau et confirmation des sauvegardes. Le code ne génère aucune clé maîtresse à l'installation.

**Accès : Core AWM > Sécurité et accès > Coffre et connexions.** Le rôle Administrer Core est requis pour les commandes de gestion. Les matrices de permissions et les sessions existantes restent accessibles depuis cette page.

Seul Core change. Hub 4.5.88, CRM 1.6.31, LeadTracker 1.11.54 et les sept autres archives sont conservés octet pour octet depuis 4.5.400. Les boutons de campagne livrés en 4.5.400 sont préservés. Aucun changement de campagne, de CPL ou de rattachement CRM n'est effectué par ce correctif.

**Il ne s'agit pas encore de la centralisation complète.** Capturia, Screpy, WooCommerce, IA, connecteurs de sites et signatures de déploiement restent sur leurs chemins historiques. Les écrans existants de saisie Twilio/Google restent compatibles. Leur déplacement exclusif dans Core, les autorisations fines par ressource et la migration des leads restent à terminer.

Les tests ont été exécutés localement. Ni l'installation réelle WordPress, ni les appels Twilio/Google Ads, ni la restauration SQL sur l'hébergement ne sont validés par ce rapport. Les sources de roadmap et les journaux sont inclus; la publication publique n'est pas confirmée.

---

## Core AWM 4.5.282 — LeadTracker / CRM Client AWM
Cette version fournit le canal d autorisation nécessaire au CRM Client AWM local et met à jour la navigation visible vers LeadTracker AWM tout en conservant les identifiants techniques historiques.

# Core AWM 4.5.281 — mises à jour locales vérifiées

La page **Core AWM → Mises à jour** ne considère plus qu’un module est réellement à jour sur le seul numéro de version. Si le numéro correspond à la publication mais que l’empreinte du build local est inconnue, le module apparaît **Build à vérifier** et **Mettre à jour Alliance** permet de réinstaller le paquet signé. La barre 100 % signifie désormais que les builds locaux sont effectivement vérifiés.

Cette version accompagne **CallTracker AWM 1.11.37**, publié sous un numéro supérieur afin de forcer l’installation du correctif Capturia sur les sites où un ancien build 1.11.36 pouvait déjà être présent.

# Core AWM 4.5.280 — import Suite déterministe
Core publie **CallTracker AWM 1.11.32 + Hub AWM 4.5.67** dans `/hub/roadmap/` avec la correction historique Google Ads des lignes à 7 %, la protection des saisies manuelles et la provenance par champ.

Core publie **CallTracker AWM 1.11.31 + Hub AWM 4.5.66** dans `/hub/roadmap/`. Le CPL mensuel expose désormais sa complétude, sa source Google Ads/manuelle/legacy, la devise, la fraîcheur et les coûts qui composent le calcul. Les frais récurrents peuvent être enregistrés par campagne et la provenance Google Ads n est plus perdue lorsqu on ajuste seulement le rabais, la réceptionniste ou les autres coûts.

# Core AWM 4.5.277 — roadmap publique CallTracker 1.11.30

Core publie le correctif UX **CallTracker AWM 1.11.30** dans `/hub/roadmap/` : le parcours natif WordPress `Modification groupée` est retiré de Campagnes, le bouton CallTracker est placé dans la barre Recherche / filtres et son panneau s ouvre hors tableau sur toute la largeur. Le moteur sécurisé de 1.11.29 demeure inchangé.

# Core AWM 4.5.276 — roadmap publique CallTracker 1.11.29

Core publie la livraison **CallTracker AWM 1.11.29** dans `/hub/roadmap/` : actions groupées métier avec aperçu serveur, permission `calltracker/approve`, jeton à usage unique, empreinte d état, verrous concurrents et journalisation. Les opérations Twilio/destructives restent séparées des actions courantes et soumises à leurs préconditions.

# Core AWM 4.5.275 — roadmap publique CallTracker 1.11.28

Core synchronise `/hub/roadmap/` avec le tri métier serveur et les vues technicien de CallTracker 1.11.28. La liste Campagnes peut maintenant être triée sur Leads 30 j, Historique total et CPL avant pagination; les vues Toutes, À vérifier, Sans client et Sans numéro sont mémorisées par technicien. Les 214 appels historiques restent documentés comme écart connu non bloquant.

# Core AWM 4.5.274 — roadmap publique CallTracker 1.11.27

Core synchronise `/hub/roadmap/` avec la nouvelle vue **Historique total** de CallTracker. Les campagnes existantes peuvent maintenant montrer leur cumul d appels et de formulaires séparément de la fenêtre récente de 30 jours. Le reliquat de 214 appels historiques est conservé comme écart connu non bloquant afin de ne plus ralentir la suite des travaux.

## Core AWM 4.5.273 — publication de la validation terrain CallTracker
Core synchronise la page publique `/hub/roadmap/` avec l état observé sur Alliance après la correction CallTracker 1.11.26. Le cas VMV-NAT confirme que les formulaires historiques affichent désormais le vrai courriel du prospect, le téléphone et la page source. La roadmap conserve explicitement le reliquat de 214 appels historiques comme travail actif plutôt que de déclarer la migration complète.

## Core AWM 4.5.272 — contexte CallTracker du nouveau dashboard
- Reconnaît `admin.php?page=callink-dashboard` comme un écran CallTracker dans le shell partagé.
- Affiche donc le header **CallTracker AWM** (et non Hub AWM) avec l onglet **Tableau de bord** actif.
- Ajoute le dashboard client/campagnes à la navigation CallTracker sans modifier les autres modules.

## Core AWM 4.5.271 — inventaire formulaires à la demande
- Capture l inventaire Gravity Forms/Elementor présent dans `update/status` et l enregistre par `site_id` Connector.
- Réutilise les verrous anti-rafale existants : une seule lecture distante par site à la fois.

## Core AWM 4.5.270 — inventaire formulaires par site
- Transporte et persiste de façon site-scoped l inventaire Gravity Forms/Elementor fourni par Hub Client pour l UX CallTracker.

### Transport paquet renforcé — Core 4.5.266
Le déploiement manuel bascule automatiquement vers le transport REST signé si le premier téléchargement retourne un paquet vide.

### Déploiement flotte sans garde Recovery bloquante — Core 4.5.265
Pour accélérer et fiabiliser le déploiement massif, Recovery reste livré mais est temporairement retiré du chemin obligatoire. L Autopilote conserve les contrôles de transport, HMAC, SHA-256, sauvegarde locale, rollback, vérification fraîche et no-downgrade. La réintégration de Recovery est prévue au roadmap futur comme certification asynchrone indépendante.

### Bootstrap fiable Hub → Tech → Recovery — Core 4.5.264

Tech est maintenant une dependance systeme du Hub Client : tout site connecte doit recevoir Tech automatiquement et le conserver actif/courant, sauf desactivation humaine explicite dans la fiche CRM. Une version Tech absente, inactive ou inferieure a la publication active est corrigee **avant** Recovery. Les inventaires utilisent aussi une garde anti-regression afin qu une telemetrie plus ancienne ne remplace plus un etat plus recent deja confirme.

### Même flotte écran / Autopilote — Core 4.5.260

Core utilise maintenant le même critère de connexion dans l écran **Sites connectés** et dans le worker Autopilote. Un site déjà appairé avec `connector_state=connected` reste admissible au worker même si le champ `runtime_authorized` n a pas encore été persisté à `1`. Cela corrige le cas terrain où l écran affichait 15 sites mais le worker ne traitait que les 4 premiers avant de passer à `idle`.

Le parcours reste fail-closed : chaque site doit toujours réussir Hub Client, Recovery et les vérifications de déploiement avant toute mise à jour automatique. Les sites réellement déconnectés ou les clients non opérationnels restent exclus.

### File Autopilote jusqu au dernier site — Core 4.5.259

Core corrige la déduplication des événements `wp_schedule_single_event` qui pouvait interrompre une vague après quelques clients. Chaque lot suivant reçoit maintenant un jeton unique, est rendu immédiatement exécutable puis déclenché par le loopback cron. Le worker reste `queued` tant que le curseur n a pas atteint le dernier site; `idle` signifie désormais que la vague est réellement terminée.

### File Autopilote persistante — Core 4.5.258

Le worker de flotte enchaîne maintenant les lots après libération de son verrou. Le bouton **Lancer l Autopilote maintenant** démarre la file complète, sans reload destructif après le premier client. L interface rafraîchit silencieusement les lignes sélectionnées pendant que les lots suivants sont dispatchés en arrière-plan. La garde Recovery reste indépendante pour chaque site.

### Autopilote zero-clic — Core 4.5.257
Le parcours normal ne demande plus de preparer Recovery manuellement. Core reconcilie d abord Hub Client, lance ensuite la preparation Recovery complete, attend `recovery_ready_for_auto=1`, puis poursuit Tech et les autres mises a jour. Une intervention humaine n est demandee que si un controle objectif echoue reellement.

# Hub Core 4.5.255 — Roadmap publique Suite 4.5.319

Synchronise /hub/roadmap avec l UX Campagnes Appels/Formulaires, le pilotage Elementor/Gravity Forms depuis Alliance et la suppression logique sécurisée des fiches clients CRM.

# Core AWM 4.5.254 - Autopilote Recovery auto-réparable

Core 4.5.254 conserve le transport par paquets XHR de 512 Ko et ajoute la préparation Recovery assistée pour la flotte. Lorsqu une mise à jour Hub Client ou Tech est détectée, l Autopilote tente maintenant de réparer/inspecter la porte Recovery avant le déploiement.

Si le périmètre Recovery a déjà été confirmé par un administrateur, Core peut relancer automatiquement le vrai test isolé fichiers + SQL et continuer le déploiement dans le même passage dès que `recovery_ready_for_auto=1`. Si cette confirmation n existe pas encore, l Autopilote reste fail-closed et indique clairement qu une validation humaine unique est requise.

La page **Core AWM > Mises à jour** ajoute **Préparer Recovery** pour traiter les sites sélectionnés avec une seule confirmation de vague. Chaque site reste validé séparément (base dédiée, implantation/Vault, route, point complet, test fichiers + SQL), et un échec n arrête pas les autres. Après validation d un site, l Autopilote est relancé automatiquement.

# Core AWM 4.5.252 - import par paquets XHR sans iframe

Le televersement Suite/module est decoupe en paquets de 512 Ko. Chaque paquet est envoye exclusivement par `XMLHttpRequest`, d abord vers `admin-ajax.php` construit depuis l origine exacte du `wp-admin` ouvert. Un troisieme essai XHR peut utiliser la page courante comme endpoint de repli.

Le transport iframe a ete retire de l importeur: aucune creation d iframe, aucun `contentDocument` et aucune lecture `contentWindow.document` ne participent au televersement. Le serveur assemble ensuite les paquets, verifie la taille et le SHA-256, puis transmet le paquet valide au traitement AWM.

La correction conserve les nonces, la limite totale de 256 Mo, la validation des manifests, README/CHANGELOG/ROADMAP, le depot prive et la regle no-downgrade.

# Core AWM 4.5.249 - reprise automatique des transactions v3 supersedees

Lors d un deploiement administrateur manuel, une transaction atomic_v3 reste toujours unique par module. Si une ancienne transaction Tech AWM (ou autre module hors Hub Client) vise une version inferieure a la cible courante, Core la ferme avant de creer la nouvelle transaction : finalisation/commit si elle est encore saine, sinon rollback lie au `deployment_id`. Les transactions avant promotion (`verified`/`staged`) peuvent etre abandonnees apres 5 minutes sans modifier le plugin actif. Aucun downgrade automatique n est autorise.

Cette correction vise notamment les sites deja harmonises en Hub Client 1.14.3 qui restaient bloques sur `awm_deploy_resume_target_conflict` pour Tech AWM. Hub Client reste un plugin WordPress classique et aucune dependance MU n est reintroduite.

# Core AWM 4.5.248 - architecture Hub simplifiee

Hub Client AWM 1.14.2 est de nouveau un plugin WordPress classique. Le chemin normal de mise a jour est: paquet publie par Core -> verification HMAC/SHA-256 -> staging/backup -> promotion atomique -> nouvelle requete -> preuve version + actif + `classic_mode` + `boot_ok` -> commit.

Le bouton **Harmoniser Hub Client** applique cette logique a toute la flotte, quatre sites a la fois. Un site qui echoue est journalise et la vague continue. Tech Rescue et un ancien AWM System Agent peuvent encore etre utilises comme secours de transition pour remettre en ligne un Hub qui ne repond plus, mais ils ne sont plus requis dans l etat final.

# Core AWM 4.5.247

La remise en état flotte est maintenant une **réharmonisation**, pas seulement un patch réservé aux sites qui possèdent déjà System Agent. Core tente System Agent en premier, puis utilise l ancien canal Hub seulement s il répond encore de façon authentifiée. Hub Client 1.14.1 installe ensuite System Agent 2.0.1 sans déplacer son propre runtime dans MU. Les sites sans canal sûr sont laissés intacts et signalés, mais les autres continuent d être traités.

# Core AWM 4.5.245 - plan de contrôle indépendant

La reprise flotte ne dépend plus du runtime Hub Client. Core privilégie maintenant **AWM System Agent MU 2.0.0**, un agent minimal installé dans `mu-plugins` qui reste disponible même lorsque Hub Client est désactivé par le coupe-circuit.

Depuis le bouton Réparer, Core peut demander à cet agent d installer le ZIP Hub Client signé, vérifier son SHA-256, conserver une sauvegarde locale, promouvoir la version de façon atomique puis l activer pour une nouvelle requête. Hub Client 1.14.0 est ensuite validé en `safe_legacy`.

Pour Hub 1.14.0+, Core ne relance plus le vieux mécanisme de migration MU automatique.

## Core AWM 4.5.244 - restauration de flotte sans fatal Hub Client

Cette version transforme le garde MU en précondition transactionnelle. Pour Hub Client 1.13.9+, Core ne remplace jamais les fichiers tant qu une nouvelle requête n a pas confirmé `rescue_legacy` (ou un runtime MU déjà complet). Un échec de pré-armement bloque avant écriture et laisse le site dans son état actuel.

La réparation d urgence et le déploiement utilisent maintenant un seul pré-armement, ce qui évite deux transactions Rescue concurrentes. Recovery et l Autopilote restent strictement fail-closed.

## Core AWM 4.5.243 - garde MU précoce et restauration de flotte

Core arme désormais **AWM Hub MU Rescue 1.1.3 avant** de remplacer Hub Client sur un site dont la migration MU n est pas saine. L activation du secours installe un MU-plugin très tôt dans l ordre de chargement; à la requête suivante il force la copie Hub Client legacy à rester active et place la migration en `rescue_legacy`.

Pour une réparation administrateur manuelle vers Hub Client 1.13.8+, Core accepte ensuite deux preuves distinctes : la preuve MU normale, ou une preuve explicite `rescue_legacy` où la version cible est réellement chargée mais MU est différé. Dans le second cas, Core ferme la transaction avec `commit_mode=legacy_rescue` puis peut poursuivre Tech AWM. L Autopilote reste bloqué parce que Hub Client force `recovery_ready_for_auto=0` dans ce mode.

Le but est de rétablir les mises à jour sur les clients actuellement en erreur sans continuer à faire rollbacker une version Hub saine simplement parce que le cutover MU est encore défectueux.


## Patch flotte 4.5.246
Le bouton **Patch Hub flotte** orchestre la remise en état Hub Client sur tous les sites visibles, deux à la fois. Cette action utilise uniquement AWM System Agent 2.x et exige la preuve `safe_legacy + boot_ok`. Un site sans agent est bloqué sans modification. Trois échecs consécutifs stoppent automatiquement la vague.

### Preparation Recovery sur hebergement mutualise
Core 4.5.256 sait que Hub Client/Recovery peuvent valider le SQL sans CREATE DATABASE. La preparation en lot tente le parcours complet et ne debloque l Autopilote qu apres preuve de restauration et nettoyage du sandbox.


## Transport de paquet 4.5.267
Lors d'une réparation manuelle, Core peut basculer automatiquement entre admin-post, REST, admin-ajax et un endpoint frontal signé si un WAF/proxy retourne HTTP 503. La signature HMAC et le SHA-256 restent obligatoires.


## Transport statique éphémère 4.5.268
Pour les déploiements manuels/réparations, Core prépare maintenant le ZIP publié dans un chemin public temporaire à URL aléatoire de 256 bits. Le fichier est déchiffré et vérifié côté Alliance avant exposition; le Connector vérifie à nouveau le SHA-256 avant installation. Ce chemin retire PHP/WordPress du flux binaire et contourne les WAF/proxy qui renvoyaient un HTTP 503 ou un corps 200 vide. Les endpoints WordPress précédents restent disponibles en repli.


## Protection anti-rafale 4.5.269
Core cadence maintenant la flotte a un site par lot, espace les continuations et coalesce les synchronisations concurrentes d un meme site. Le suivi navigateur est strictement sequentiel. Les enveloppes JSON valides peuvent etre recuperees lorsqu un hebergeur ajoute un BOM ou un warning autour de la reponse, mais un corps vide/non JSON reste refuse.

## Design Composer v2 — Core 4.5.309
Le profil visuel est composé de Famille, Couleur, Typographie, Surface, Mouvement, Light/Dark et Densité. Les piles typographiques sont locales/système et le mouvement respecte `prefers-reduced-motion`.


### 4.5.312
Le preflight de Suite lie chaque avancement roadmap a la version source exacte du module modifie. Le loader de secours utilise aussi l accent actif pour son backdrop floute.
- 4.5.317 : le choix Couleur du Design Composer pilote maintenant aussi les alias visuels legacy; les cartes Hub Clients restent des scopes client isolés.

## 4.5.318
Le shell Core peut maintenant auto-réparer la route `awm-hub-clients` afin que le Design Composer principal s applique même lorsque le header partagé n est pas rendu.
Dernier correctif : 4.5.319 unifie Light/Dark entre Core et les routes legacy comme Hub AWM > Clients.



---

## ROADMAP.md

# Core AWM 4.5.328

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

Core 4.5.328 consigne le contrat d’identité de l’en-tête et ajoute favicon_url au payload utilisateur authentifié, depuis le favicon choisi ou détecté dans l’identité canonique du client. La mémoire reçoit une décision, avec 144 entrées antérieures conservées. Permissions, sessions, coffre, catalogue et compilateur restent sous leurs contrats existants.

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.

---

# Core AWM 4.5.327

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

Publie les recettes de prévisualisation canoniques et ajoute dans Design System & QA le parcours URL → brouillon → aperçu clair/sombre → approbation explicite → application comme défaut client. Les actions utilisent les permissions Core/CRM et des nonces; aucun modèle n’est approuvé automatiquement. Le registre conserve des configurations contrôlées et leur empreinte; la bibliothèque réutilise ou télécharge les fichiers de police manquants, avec variantes et origine. La mémoire ajoute deux décisions en conservant les 142 règles précédentes.

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.

---

## 4.5.326 — 2026-10-22

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

Le contrat d’apparence valide les deux profils avant toute écriture. Une bascule seule enregistre uniquement le choix Auto/clair/sombre et préserve les profils et l’identité automatique. Le raccordement administratif applique les variables et les classes du profil correspondant au mode Core. La mémoire consigne la décision et conserve les 141 entrées antérieures.

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 4.5.325 — Suite 4.5.467

L’utilisateur a accepté la Suite **4.5.466** comme référence d’apparence puis demandé l’inscription de cette décision dans la mémoire Core, les journaux et les roadmaps. La décision `AWM-APPEARANCE-BASELINE-466-001` est ajoutée au seed `2026-10-22.4`; les 139 entrées antérieures restent identiques.

Les cartes et fiches administratives CRM et Hub conservent les couleurs et les six axes du client, avec la variante claire/sombre du Core de l’opérateur. Hub Client conserve indépendamment **Automatique · logo puis site**, **Toujours sombre** ou **Toujours clair**. La personnalisation manuelle reste prioritaire sur la réanalyse; l’affichage administratif n’écrit aucun choix client.

Le lot officiel de migration mémoire de 4.5.466 garde son identifiant immuable `2026-10-22.3`, distinct de la version du seed courant. Un site qui passe directement de 4.5.465 à cette version peut donc encore appliquer ses révisions officielles bornées, avec les mêmes empreintes autorisées et protections des révisions humaines. La nouvelle décision est insérée par le mécanisme de mémoire existant et ses événements de journalisation habituels.

La création de styles depuis une URL dans **Core → Design System & QA** reste proposée et différée. L’acceptation de la livraison ne constitue ni une installation sur l’hébergement ni une validation en production. Les résultats locaux de cette Suite sont documentés dans son rapport de validation.

## Accès au Hub Client depuis la fiche CRM

La décision `AWM-CRM-HUB-SITE-USERS-001` précise le bloc permanent **Hub Client & connexion** rendu par Hub 4.5.110 dans la fiche CRM. Quand le site principal est lié par un Connector runtime autorisé, ses comptes WordPress apparaissent avec leurs cases de sélection. Le scan et l’enregistrement utilisent l’annuaire et l’allowlist existants de Core, avec leurs permissions, le nonce CRM et le périmètre explicite du site principal. Un simple affichage ou scan n’accorde aucun accès. Les références invalides et les sélections fondées sur un annuaire périmé sont refusées. Les cases utilisent les références stables Core; une modification réelle des droits réutilise la révocation des sessions API du site concerné et les journaux Core existants.

Le raccourci **Hub Client** ouvre le portail du site appairé dans un nouvel onglet, en conservant le sous-dossier WordPress et l’authentification ou la session existante. Il ne crée pas de nouveau SSO. Les deux nouvelles décisions portent la mémoire à **141 clés uniques**, sans modifier les 139 entrées de 4.5.466. Core reste l’autorité des droits et du transport; cette interface est fournie par Hub.

---

## Livraison 4.5.324 — Suite 4.5.466

Core choisit la variante claire ou sombre des cartes et fiches administratives explicitement marquées, en conservant leurs couleurs et leurs six axes client. La synchronisation se fait dès le rendu et lors des bascules, sans écriture de préférence client. Les règles du shell respectent ces zones personnalisées. Les règles officielles de mémoire concernées évoluent par révisions bornées et vérifiées; les révisions humaines sont préservées.

## 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 4.5.323 — 2026-10-22 · Suite 4.5.464

### Maintenant

Partager le payload canonique Hub Client avec le consommateur CRM, préserver la frontière CSS des deux zones personnalisées et corriger la mémoire de la décision 4.5.463. Le thème Core reste l’autorité du shell, du header et des guides. La fiche sélectionne l’apparence claire/sombre du profil client, automatique depuis logo/site ou choisie manuellement, indépendamment du mode Core.

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 — deux pistes nouvelles différées

**Simulation de perception des couleurs du profil** : prévisualiser le profil selon plusieurs simulations de perception des couleurs pour examiner la distinction des accents et des états, sans modifier les valeurs enregistrées ni les couleurs métier. Cette capacité est distincte des contrôles de contraste et des aperçus de mode déjà prévus.

**Évolution proposée et différée — Création de styles depuis une URL dans Design System & QA**. Dans Core AWM → Design System & QA, saisir l’URL d’un site, analyser son identité visuelle et sa structure, puis proposer de nouveaux styles sous forme de tokens contrôlés. Prévisualiser chaque proposition en Light/Dark, ajuster ses paramètres, la nommer puis l’enregistrer au catalogue pour les clients après validation explicite. Évolution proposée et différée; aucune génération, activation ou publication de style n’est ajoutée dans 4.5.464. Cette piste ajoute la saisie d’une URL et la proposition de nouveaux jeux de tokens; elle complète l’éditeur de presets contrôlés, les favoris et les prévisualisations déjà prévus sans les recompter.

La revue `2026-10-22.1` relit les dix modules. Trois pistes complémentaires côté Hub concernent le verrouillage sélectif des axes, la veille des changements d’identité avant adoption et le choix de la zone utile du logo pour l’analyse. Ces cinq nouveautés restent différées; la correction immédiate ne les implémente pas. Les mentions CRM = Core de la revue 4.5.322 ci-dessous sont remplacées par cette décision.

## 2026-10-21 — Core 4.5.322 / Suite 4.5.463

### Périmètre

- Documenter l’autorité du Design Composer Core sur le dossier administratif CRM.
- Limiter les exceptions d’identité personnalisée aux scopes Hub explicitement autorisés.
- Versionner mémoire, architecture et Futur en `2026-10-21.16`; 139 règles uniques.

### Maintenant

- Exiger une preuve du chargement des CSS sur la route CRM réelle avant les mesures visuelles.
- Comparer la fiche CRM au profil Core actif, en Light/Dark et sur écran étroit; vérifier les modes Standard/Avancé.
- Consigner séparément les validations locales acquises, l’installation sur l’hébergement et la publication publique.

### Futur nouveau, différé

- Palette de commandes contextuelles : rechercher au clavier les destinations autorisées du module et du dossier actifs, sans déclencher de mutation métier lors d’une navigation.

## 2026-10-21 — Candidate Core 4.5.321 / Suite 4.5.462

### Périmètre de la candidate

- Classement exact de la route centrale Hub avant exclusion du portail client, afin que le contexte Core charge les styles du shell et des guides dans la fiche.
- Haut du shell cohérent avec le Design Composer administratif et frontière CSS de fiche conservée.
- Contrat carte/fiche : même profil effectif complet, réellement compilé et appliqué.
- Mémoire et architecture actualisées avec les six axes et les responsabilités Core/Hub.

### Maintenant

- Vérifier le classement de route et les hooks de chargement PHP avant les contrôles du haut du shell en Light/Dark et sur écran étroit.
- Comparer les six axes du profil d’une carte à ceux de sa fiche, en conservant un profil administratif distinct.
- Consigner les validations locales, WordPress et publication séparément.

### Futur nouveau, non implémenté

- Résolution des conflits de coédition du profil axe par axe, avant tout écrasement.

## 2026-10-21 — Candidate Core 4.5.320 / Suite 4.5.461

### Implémentation dans la candidate

- Frontière CSS explicite de la fiche client et de ses descendants; le shell administratif conserve son autorité sur le reste de la page.
- Retrait des neutralisations `--client-*`, sans augmentation de la spécificité des autres sélecteurs Core.
- Mémoire et architecture réconciliées avec les exceptions de carte/fiche et les familles Design Composer existantes.

### Maintenant

- Vérifier en terrain le parcours Core Dark → Hub Clients → fiche → Identité visuelle, puis le retour à la liste et la bascule Light/Dark.
- Consigner séparément les résultats locaux, la validation WordPress et la publication de la roadmap.

### Futur nouveau, non implémenté

- Favoris personnels de combinaisons Design Composer.
- Vue de lecture accessible propre à l’utilisateur, indépendante du profil client enregistré.

## 2026-10-21 — Core 4.5.317 / Suite 4.5.458

- [x] La couleur Design Composer devient l accent canonique des alias administratifs legacy.
- [x] Palette de compatibilité dérivée automatiquement pour `--awm-blue-*`, `--ci-orange`, CRM, CallTracker, Tech et Hub.
- [x] Les cartes Hub AWM > Clients sont exclues de la neutralisation admin et conservent leur thème client.
- [ ] Terrain : vérifier Arctic Cyan + Glow, Electric Orange et Rounded Violet en Light/Dark.

## 4.5.316 — 2026-10-21

- [x] Autorité Design Composer sur les racines `#wpcontent/#wpbody/#wpbody-content` de Hub Clients.
- [x] Classification liste administrative distincte du dossier identité client.
- [x] État Light/Dark unifié, sans état local concurrent.
- [x] Îlots carte client protégés via tokens `--card-*`.


## Livré 4.5.315 — 2026-10-21
- [x] Publie le catalogue Design Composer comme contrat partageable pour Hub AWM et Hub Client.
- [x] Le payload Hub Client expose catalogue, tokens compilés, source et libellé de source du thème.
- [x] Le retour au thème automatique relance réellement la détection `logo -> site Web -> thème AWM`.
- [x] Hub AWM > Clients conserve le shell administratif central tandis que les cartes clients peuvent prévisualiser leur profil propre.
- [x] Ajoute les règles de mémoire sur auto-identité, propagation du catalogue, scope de thème des services client et cartes de prévisualisation.

## 4.5.314 - Carte de message harmonisee au Design Composer
- Maintenant : supprimer le fond bleu fixe du dialogue global.
- Maintenant : reprendre surface, titre, texte, bordure, rayon et ombre du theme actif.
- Maintenant : conserver le backdrop discret de 4.5.313 sans augmenter sa teinte.

## 4.5.313 - Backdrop theme subtil
- [x] Revenir au blur historique de 3px.
- [x] Limiter la teinte theme a 8 % Light / 12 % Dark.
- [x] Retirer la saturation et la bordure fortement accentuee.
- [ ] Futur : intensite gouvernee, adaptation par luminance, QA comparee et mode reduction de transparence.

## 4.5.312 - Couverture roadmap source + backdrop du loader
- Maintenant : exiger une entree roadmap versionnee pour chaque module source modifie.
- Maintenant : backdrop des messages AWM teinte par l accent actif, avec blur et saturation controles.
- Futur : preflight generant automatiquement la matrice modules modifies -> avancements roadmap.
- Futur : capture QA automatique des overlays pour chaque couleur et Light/Dark.

## 4.5.311 - Surface & Mouvement v2
- [x] 12 styles de Surface distincts et visibles.
- [x] 12 personnalités de Mouvement distinctes.
- [x] Aperçu de surface et test de mouvement directement dans Design System & QA.
- [x] Propagation du vocabulaire aux profils clients, Hub Client et Studio.
- [x] Respect strict de `prefers-reduced-motion`.
- [ ] Futur : presets métier Surface × Mouvement validés, capture automatique des états et score de confort visuel.

## 4.5.310 - Design Composer Web
- [x] Compiler un profil Design Composer en tokens Web neutres pour Studio.
- [x] Conserver une frontière stricte : Core = moteur design, Studio = composition/layout/effets, Hub Client = application page-scoped.
- [ ] Ajouter score qualité, bibliothèque de composants gouvernés et QA responsive multi-breakpoints.
- [ ] Ajouter une publication explicite vers Elementor Global Colors/Fonts avec preview, sauvegarde et rollback.

## 2026-10-21 - Core 4.5.308
- Compositeur dynamique Style x Couleur x Light/Dark x Densite.
- Prochaines etapes : comparateur cote-a-cote, validation WCAG automatisee, QA combinatoire et historique de profils.

## Core AWM 4.5.307 / Suite 4.5.448 - table Dark et QA calculée
- [x] Neutraliser le fond clair natif `widefat striped` au repos dans la table de référence Design System.
- [x] Couvrir repos, alternance, hover, focus et sélection avec les tokens Core.
- [ ] Ajouter un scanner de styles calculés pour repérer les règles WordPress/module qui gagnent encore sur Core.
- [ ] Générer une matrice de captures preset × Light/Dark × état interactif.
- [ ] Produire un rapport de spécificité CSS lors d'une régression.
- [ ] Persister une session QA passe/à vérifier par route et preset.
- [ ] Exporter le rapport QA avec URL, preset, thème et état contrôlé.

## Core AWM 4.5.306 - intégrité de version source
- Aligner et valider automatiquement le header WordPress `Version:` et `AWM_CORE_VERSION` avant toute publication de Suite.
- Conserver ensuite le triplet exact ZIP / manifest / roadmap comme garde de publication.


## 2026-10-20 - Core 4.5.302 / Suite 4.5.442
- Sélecteur explicite de style dans Design System & QA et dans Affichage.
- Fermeture CSS terrain : priorité Core renforcée pour supprimer les arrondis legacy restants.
- Futur prioritaire : diff visuel automatique, lint CSS, grille d espacement, responsive multi-breakpoints et audit WCAG.

## Maintenant - 4.5.298 / Suite 4.5.438
- [x] Auditer les pages, sous-pages, routes pont et onglets des neuf modules administratifs centraux.
- [x] Corriger le melange Light/Dark observe dans Hub > Clients.
- [x] Imposer un etat de theme canonique Core et synchroniser les alias legacy.
- [x] Couvrir les ecrans natifs WordPress Campagnes/Appels de LeadTracker.
- [x] Neutraliser les couleurs/gradients/ombres legacy des surfaces admin sans recolorer les apercus metier.
- [x] Garder Hub Client completement exclu du Design System administratif.
- [x] Memoire/Architecture/Revue Futur `2026-10-20.4`, 111 regles.
- [ ] Validation terrain : parcourir Core, Hub, CRM, LeadTracker, Stats, Assistant, Soutien, Studio et Tech en Light puis Dark.
- [ ] Prochaine nouveaute : matrice de captures visuelles automatisees Light/Dark par route.
- [ ] Ajouter un lint CSS de livraison pour detecter gradients decoratifs, rayons > 4 px et couleurs legacy sur les primitives communes.
- [ ] Ajouter des snapshots de contraste WCAG sur les composants admin critiques.
- [ ] Centraliser le registre des routes AWM afin que toute nouvelle page herite automatiquement du Design System.

## Maintenant - 4.5.297
- [x] Centraliser le style administratif dans Core.
- [x] Nouveau langage visuel bleu et carre, distinct des interfaces clientes.
- [x] Charger la couche visuelle Core en dernier sur tous les modules AWM centraux.
- [x] Exclure Hub Client de cette couche globale.
- [x] Neutraliser dans l admin central les grands aplats/gradients de branding client tout en gardant logo et identite.
- [x] Memoire/Architecture/Revue Futur 2026-10-20.3.
- [ ] Valider visuellement Core, Hub, CRM, LeadTracker, Stats et Tech sur Alliance.
- [ ] Migrer progressivement les anciennes declarations visuelles locales vers les tokens Core afin de reduire encore le CSS duplique.

## Maintenant - 4.5.296
- [x] Registre générique des CRM externes par client dans Core.
- [x] Aucun secret fournisseur stocké dans la fiche client; clés conservées dans Core AWM.
- [x] Capturia adopté comme premier fournisseur sans généraliser son affichage aux autres clients.
- [x] Désactivation explicite persistante pour éviter qu une ancienne campagne réactive visuellement le CRM.
- [ ] Terrain : confirmer Vendre Maison Vite = Capturia visible et Allo Déménagement = aucun CRM visible en Standard/Guidé.
- [ ] Futur : contrat de santé fournisseur, rotation de credential, mapping par fournisseur et journal d intégration unifié.

## Maintenant - 4.5.295
- Conserver la livraison Capturia immediate validee terrain.
- Garantir que les champs identite Capturia proviennent de valeurs humaines et jamais d un email/telephone/URL.
- Valider le prochain vrai lead sans formulaire test artificiel.

## Livré localement — Core AWM 4.5.294 · Affichage par utilisateur
- [x] Ajouter les modes Guidé / Standard / Avancé au shell commun AWM.
- [x] Mémoriser le choix par utilisateur WordPress.
- [x] Permettre le basculement instantané depuis l entête pour le développement et la formation.
- [x] Garder Parcours guidés / Aides contextuelles / Options avancées dans Affichage.
- [x] Garantir qu aucun mode ne change une donnée métier ou une permission.
- [x] Fournir un composant de parcours guidé réutilisable par les modules.
- [ ] Valider le basculement sur WordPress Alliance en Guidé / Standard / Avancé.
- [ ] Confirmer l entrée V4.5.433 sur la roadmap publique après installation.

---

## 2026-10-15 - 4.5.293 / Suite AWM 4.5.415 - loi Capturia automatique + seed Mémoire versionné

- Ajoute la règle critique `AWM-CAPTURIA-AUTO-ALL-FORMS-001` : quand Capturia VMV-NAT est actif, tout formulaire capturé du site principal est routé automatiquement, sauf mapping explicite vers une autre campagne.
- Ajoute `AWM-SUITE-PACKAGING-SAFETY-001` après l incident 4.5.413 : aucun arbre de travail ne doit entrer dans un ZIP Suite publié.
- Corrige le mécanisme de seed : `SEED_VERSION` passe à `2026-10-15.4` afin que les nouvelles lois ajoutées depuis 4.5.411 soient réellement importées dans une base Core déjà initialisée, sans réécrire les règles existantes.
- Architecture et Revue Futur passent à `2026-10-15.4`.

## 2026-10-15 - 4.5.292 / Suite AWM 4.5.413 - loi multi-formulaires Capturia et diagnostic par lead

- Ajoute la regle critique Memoire `AWM-CAPTURIA-FORM-SOURCES-001`: un moteur de formulaire explicitement cable et supporte ne doit jamais etre ignore par le routage Capturia VMV-NAT.
- Memoire AWM embarquee: 104 regles.
- Architecture AWM passe a `2026-10-15.3` et formalise le circuit Elementor / Gravity Forms / Contact Form 7 -> VMV-NAT -> Capturia -> preuve technique LeadTracker.
- Le canal Core `client/forms/capturia-delivery` transporte maintenant source, identifiant du formulaire, phase et curseur de notes, toujours sans PII.
- La regle d heure canonique existante est appliquee au diagnostic LeadTracker: stockage UTC, affichage America/Toronto HAE/HNE.
- Revue Futur `2026-10-15.3`: prochaine nouveaute prioritaire proposee, matrice de sante des sources et alertes recu-sans-preuve.
- Aucun lead, envoi Capturia, migration ou deploiement distant n est execute par Core a l installation.

## 2026-10-15 - 4.5.291 / Suite AWM 4.5.412 - Architecture du pipeline CRM et loi de provenance

- Met à jour **Architecture AWM** vers `2026-10-15.2` : CRM AWM devient explicitement la source de vérité des opportunités et de leur état commercial.
- Ajoute le flux transversal **Interaction CallTracker → opportunité CRM** : création explicite, référence source stable/idempotente, pipeline CRM, issue Gagné/Perdu.
- Ajoute la règle Mémoire `AWM-CRM-OPPORTUNITY-SOURCE-001`; la Mémoire Core contient maintenant 103 règles embarquées.
- Le déplacement d une opportunité ne peut jamais modifier le lead/appel/formulaire source, la campagne, le CPL ni sa qualification opérationnelle.
- La revue Futur `2026-10-15.2` confirme le pipeline CRM 1.6.33 comme vraie nouveauté de cette Suite et conserve les prochaines nouveautés de chacun des dix modules.
- Aucun lead, opportunité, campagne, facture, CPL ou statut n est créé/modifié par Core à l installation.
- Les routes de sous-menu WordPress restent enregistrées conformément à la règle de stabilité 4.5.403.

## 2026-10-15 - 4.5.290 / Suite AWM 4.5.411 - Mémoire, architecture et revue Futur obligatoires

- Ajoute **Core > Outils avancés > Architecture AWM**, un registre en lecture seule et exportable des responsabilités, sources de vérité, frontières de stockage, flux critiques et dépendances de la Suite.
- Ajoute un snapshot **Revue Futur** couvrant les dix modules : maintenance/correctifs, améliorations et vraies nouveautés, recoupé avec la roadmap publique consultée en direct avant le build.
- Ajoute les règles Mémoire `AWM-ARCHITECTURE-SOURCE-001`, `AWM-SUITE-FUTURE-REVIEW-001` et `AWM-CAPTURIA-CRM-PII-001`; le seed passe à `2026-10-15.1` sans réécrire les révisions existantes.
- Les futures publications de Suite, une fois Core 4.5.290 actif, doivent déclarer `architecture_contract` et `future_review` dans leur manifeste, avec couverture des dix modules et URL de roadmap publique Alliance.
- Architecture Capturia clarifiée : Capturia reçoit les données personnelles utiles du prospect VMV-NAT; seule la table de preuve AWM reste PII-free.
- Aucun connecteur, campagne, CPL, prospect, déploiement distant ou migration métier n est lancé par cette version. Seul Core change.

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

- Ajoute le canal Connector authentifié `client/forms/capturia-delivery` pour recevoir du site Vendre Maison Vite une preuve technique PII-free après l envoi d un formulaire VMV-NAT vers Capturia.
- Core vérifie le client, le site appairé et l instance avant de transmettre le reçu à LeadTracker; aucune clé Capturia ni donnée nominative n est incluse dans ce reçu.
- Le canal ne crée ni contact, ni campagne et ne modifie aucun CPL. Les outils et la clé API Capturia restent centralisés dans Core.
- Mémoire de développement : règle `AWM-CAPTURIA-PROOF-ARCHIVE-001` ajoutée; les règles existantes sont conservées.

## 2026-10-15 - 4.5.288 / Suite AWM 4.5.405 - Capturia dans Core

- Ajoute **Capturia - Vendre Maison Vite** dans `Core AWM > Connexions > Coffre et cles`.
- La nouvelle cle API peut etre remplacee directement dans Core, sans trousseau v2 obligatoire pour cette operation; elle reste chiffree au repos par le coffre Core existant.
- Bouton de test en lecture uniquement (`/me`, un contact, une source); aucune ecriture fournisseur durant le test. Les scopes d ecriture sont seulement detectes et affiches.
- La cle n est jamais reaffichee ni journalisee. Capturia reste strictement limite a Vendre Maison Vite.
- La connexion peut ensuite etre promue dans le trousseau v2 lorsque celui-ci est prepare.
- LeadTracker 1.11.56 lit cette cle Core en priorite et conserve l ancienne cle par campagne uniquement comme repli de compatibilite.
- Aucun lead, CPL, source Capturia, campagne ou statut commercial n est modifie lors de l installation.

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

Canal CRM client prive dans Core, sans stockage metier parallele; garde client/site/instance/autorisation et chiffrement Core existant.

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.

---

## 2026-10-14 - Core 4.5.286 / Suite 4.5.403 - Acces aux mises a jour retabli

- Regression 4.5.285 reproduite : compact_menu retirait les routes secondaires de `$submenu`. Le parent WordPress devenait vide et le hook recherche ne correspondait plus au callback enregistre, causant un faux refus d'acces.
- Toutes les routes enregistrees restent dans le registre WordPress. Le menu conserve cinq rubriques visibles; seules les lignes secondaires du menu lateral sont masquees par une classe CSS.
- Les permissions, callbacks, nonces, moteurs de mise a jour, import par paquets et Recovery ne sont pas modifies. Les extensions tierces du menu restent visibles.
- Secours distinct `awm-core-menu-rescue` 1.0.0 : restaure temporairement le menu complet uniquement sur Core 4.5.285, sans installer Core, sans ecriture metier et sans neutraliser les protections d'installation. Inerte sur 4.5.286.
- Memoire : nouvelle regle AWM-CORE-NAV-ROUTES-001; 95 regles precedentes preservees; seed 2026-10-14.3; schema DB inchange.
- Tests locaux de routage/permissions et rendu de l'import. Pas de validation sur WordPress Alliance, ni de deploiement ou de restauration SQL reels. Roadmap publique non verifiee.

---

## 14 octobre 2026 - Core AWM simplifié (4.5.402 / 4.5.285)
### Codé et validé localement, essai pilote requis
Cinq espaces, accueil par tâches, liens historiques conservés, recherche d'outils selon les droits, CSS Core clair/sombre et correctif Mémoire AWM. Diagnostics en second niveau; pas de changement des moteurs de coffre ou de déploiement.

### Prochain contrôle terrain
Importer sur un pilote, comparer versions effectives, ouvrir les anciennes URL, tester les profils autorisés et refusés, relire les formulaires de coffre/import/utilisateurs/Recovery. Vérifier le contraste avec les personnalisations réelles et l'absence de régression sur Hub, CRM, LeadTracker et Tech. Publier puis vérifier la roadmap publique : non confirmé ici.

### Architecture suivante, non livrée par ce correctif UX
Centraliser dans Core les connecteurs et outils API restants; CRM Client doit devenir le stockage métier chiffré et le registre unique des prospects à vie par entreprise. LeadTracker consultera sans copie persistante; Stats et CPL consommeront les indicateurs nécessaires. Audio conservé chez Twilio, références seulement dans CRM Client. Le statut commercial restera indépendant des campagnes et de la collecte. La nouvelle navigation prépare ces travaux sans les simuler.

---

## Historique conservé

## Suite 4.5.401 / Core 4.5.284 - état exact du chantier

Les cases cochées indiquent du code livré et testé localement, pas une validation production.

- [x] Service Core de chiffrement v2 avec trousseau externe, rotation conservant les anciennes clés et index stable par client.
- [x] Écran Coffre et connexions avec contrôles d'accès, confirmations, migration/relecture et diagnostic sans secret affiché.
- [x] Trois configurations globales Twilio/Google Ads centralisables sans changer leurs consommateurs existants.
- [x] Tests cryptographiques, erreurs/écritures/concurrence simulées, fichier privé, CLI, formulaire et responsive local.
- [x] Mémoire, README, CHANGELOG, notes, guide technique, validation et manifeste synchronisés.
- [ ] Valider sauvegarde/restauration, WordPress SQL réel et connexions fournisseurs sur un pilote avant généralisation.
- [ ] Migrer Capturia, Screpy, IA, WooCommerce et autres accès; consolider leur configuration uniquement dans Core.
- [ ] Migrer les secrets de connecteurs/déploiement avec protocole de rotation authentifié sans rupture des sites.
- [ ] Enforcer les autorisations fines client/site/utilisateur/opération à chaque API métier; pas de confiance dans un simple nom de module transmis.
- [ ] CRM Client unique stockage des leads chiffrés et des références Twilio. LeadTracker lecteur autorisé sans copie persistante; Stats/CPL seulement indicateurs non nominatifs.
- [ ] Registre d'acquisition unique à vie par client CRM, import historique idempotent/ambiguïtés, attribution et calcul CPL corrigé après validation.
- [ ] Activation CRM Client pour tout client possédant une campagne, découplée du statut commercial. Ne pas retirer les autres garde-fous de suppression, archivage, droits ou identité.
- [ ] Publication visible de la roadmap en ligne et validation terrain de cette version.

Les fichiers audio restent chez Twilio. Aucun rapatriement ni suppression d'enregistrement fournisseur n'est prévu dans cette architecture.

---

## Phase pilote — 4.5.283 / partage sécurisé de la connexion Capturia existante
Nouvelle route Connector de délivrance limitée au bon client/site/campagne SEO, données protégées HTTPS, fail-closed; conserver l'audit et vérifier sur un WordPress réel avant publication publique.

# Core AWM 4.5.282 — socle LeadTracker / CRM Client
- [x] Branding visible LeadTracker avec compatibilité technique CallTracker.
- [x] Route Connector site-scoped pour l état des modules.
- [x] Onglet Câblage des leads.
- [ ] Contrat de permissions par famille de connecteur et type de donnée.
- [ ] Consentement révocable et traçable pour les exports identifiables.

## 4.5.281 — fiabilité de l’état Mises à jour
- [x] Ne plus afficher 100 % lorsqu’un module de même version a une empreinte locale inconnue.
- [x] Afficher **Build à vérifier** / **Build différent** au lieu de **À jour** dans ces cas.
- [x] Autoriser une réinstallation sûre d’un même numéro de version depuis le paquet signé lorsque le build local n’est pas vérifié.
- [x] Conserver Core en dernier, les sauvegardes locales, SHA-256, validation de version et réactivation.
- [x] Republier CallTracker sous 1.11.37 afin de forcer le correctif Capturia même si 1.11.36 est déjà installé.
- [ ] Validation terrain : confirmer que la Suite 4.5.366 affiche Core 4.5.281 + CallTracker 1.11.37 comme mises à jour, puis que la barre atteint 100 % seulement après installation réussie.

## 4.5.280 — import Suite déterministe
- [x] Résoudre le paquet de chaque module depuis le nom exact déclaré dans le manifeste avant tout repli par préfixe.
- [x] Conserver la validation stricte des versions et SHA-256.
- [x] Éviter qu’un ancien ZIP résiduel d’une Suite ne bloque la publication du bon paquet.

## 4.5.279 — synchronisation CPL provenance
- [x] Publier CallTracker 1.11.32 et Hub 4.5.67 dans la roadmap publique.
- [x] Documenter la priorité Manuel > Auto et le backfill contrôlé des lignes 7 %.

## 4.5.278 — synchronisation CPL complet
- [x] Publier CallTracker AWM 1.11.31 et Hub AWM 4.5.66 dans la roadmap publique.
- [x] Publier le statut mensuel CPL Complet / À compléter avec source, devise et fraîcheur.
- [x] Documenter les paramètres mensuels rabais / réceptionniste / autres coûts et leur application automatique.
- [x] Préserver la provenance Google Ads lors d une modification des frais annexes.
- [x] Publier la synchronisation Google Ads de toutes les campagnes mappées avec progression.
- [x] Conserver les 214 appels historiques manquants comme écart connu non bloquant.
- [ ] Validation terrain : confirmer un mois Google Ads réel, puis modifier uniquement les frais annexes et vérifier que la source reste Google Ads.
- [ ] Validation terrain : lancer « Synchroniser toutes les campagnes » et confirmer que le cycle atteint toutes les campagnes mappées.
- [ ] Confirmer `/hub/roadmap/` après installation de la Suite correspondante.

## 4.5.277 — synchronisation CallTracker 1.11.30
- [x] Publier le correctif UX des actions groupées CallTracker 1.11.30.
- [x] Retirer de la roadmap opérationnelle le parcours natif WordPress `Modification groupée` au profit du seul panneau CallTracker.
- [x] Documenter le panneau pleine largeur dans la barre Recherche / filtres.
- [x] Conserver les garde-fous serveur 1.11.29 sans modification.
- [ ] Confirmer `/hub/roadmap/` après installation de la Suite correspondante.

## 4.5.276 — synchronisation CallTracker 1.11.29
- [x] Publier CallTracker 1.11.29 et les actions groupées métier guidées.
- [x] Exposer Activer/Pause/Réattribuer comme actions courantes avec aperçu serveur.
- [x] Documenter Archive/Corbeille/Libérer Twilio/Supprimer comme zone sensible avec confirmations et garde-fous.
- [x] Marquer 1.11.28 tri métier + vues technicien comme validé terrain.
- [x] Conserver l écart historique de 214 appels comme non bloquant.
- [ ] Confirmer `/hub/roadmap/` après installation de la Suite correspondante.

## 4.5.275 — synchronisation CallTracker 1.11.28

- [x] Publier dans `/hub/roadmap/` le tri métier serveur de CallTracker.
- [x] Publier les vues technicien Toutes / À vérifier / Sans client / Sans numéro.
- [x] Conserver l écart de 214 appels historiques comme non bloquant.
- [ ] Confirmer la page publique après installation de la Suite 4.5.354.

## Core AWM 4.5.274 — historique total CallTracker publié
- [x] Publier CallTracker AWM 1.11.27 dans la roadmap publique.
- [x] Marquer **Historique total dans Campagnes** comme Livré.
- [x] Documenter la séparation entre activité 30 jours et historique cumulé appels + formulaires.
- [x] Reclasser les 214 appels historiques restants comme écart connu non bloquant.
- [ ] Validation terrain : confirmer après installation que `/hub/roadmap/` affiche CallTracker 1.11.27 et que VMV-NAT/Soltech montrent les totaux historiques.

## Core AWM 4.5.273 — roadmap publique terrain
- [x] Publier la validation terrain du correctif formulaires historiques CallTracker 1.11.26.
- [x] Marquer le cas témoin VMV-NAT comme conforme : vrai courriel, téléphone et page source.
- [x] Afficher publiquement l état réel de la réintégration : 44 712 / 44 712 formulaires et 69 092 / 69 306 appels présents.
- [x] Conserver les 214 appels historiques manquants dans **Maintenant**, sans les masquer comme terminés.
- [ ] Validation terrain restante : réparer uniquement les 214 appels refusés et confirmer 69 306 / 69 306.

## Core AWM 4.5.272 — livré / validation terrain
- [x] Identifier `callink-dashboard` comme contexte CallTracker dans le shell partagé.
- [x] Afficher le header CallTracker AWM et rendre l onglet Tableau de bord actif.
- [x] Synchroniser la roadmap publique avec le dashboard clients/campagnes, le détail complet des formulaires et la récupération audio Twilio.
- [ ] Validation terrain : confirmer le header, un formulaire Elementor complet et la lecture d un appel dont le Recording SID local était absent.

## Core AWM 4.5.271 — livré / validation terrain
- [x] Stocker l inventaire formulaires provenant de `update/status`.
- [x] Alimenter CallTracker par site Connector exact.
- [x] Respecter la déduplication/verrou d inventaire par site.
- [ ] Valider la détection immédiate Soltech racine + `/region`.

## Core AWM 4.5.270 — inventaire formulaires par site
- Transporte et persiste de façon site-scoped l inventaire Gravity Forms/Elementor fourni par Hub Client pour l UX CallTracker.

## Livré 4.5.266
- Repli de transport automatique sur paquet vide (`awm_update_download_empty`).
- Conserver Recovery au roadmap futur comme certification asynchrone non bloquante.

## Livré 4.5.265
- Recovery temporairement retiré du chemin bloquant de l Autopilote pour stabiliser la flotte.
- Statut opérationnel simplifié : Hub/Tech/modules conformes = `À jour`.
- Les mécanismes Recovery restent dans le code et la Suite.

## Futur — réintégration Recovery
- Réactiver Recovery uniquement après validation terrain de la flotte.
- Le remettre comme certification asynchrone indépendante qui ne bloque jamais le worker principal.
- Réutiliser les preuves fichiers + SQL, sandbox et rollback sans ralentir le déploiement Hub/Tech.
- Ajouter un tableau séparé de santé Recovery et des alertes ciblées au lieu de bloquer toutes les mises à jour.

## Livré 4.5.264
- [x] Statut final explicite `À jour · Recovery certifié`.
- [x] Certification Recovery des WordPress utilisant une base partagee avec isolation par prefixe.

## 4.5.263 — Tech systeme par defaut + inventaire anti-regression
- [x] Tech actif par defaut; seule une desactivation manuelle CRM explicite le coupe.
- [x] Installer/activer Tech automatiquement des le pairing Hub Client.
- [x] Mettre Tech a niveau avant Recovery lorsqu une version plus recente est publiee.
- [x] Ne plus laisser Recovery bloquer l installation ou la mise a niveau de Tech.
- [x] Empêcher une ancienne telemetrie d ecraser une version Hub Client/Tech plus recente deja confirmee.
- [x] Conserver le parcours Hub -> Tech -> Recovery -> autres mises a jour, avec rollback et fail-closed Recovery.
- [ ] Validation terrain : Climat NordSud et Plomberie Soltech ne doivent plus rester `Tech a installer`; Demenagement Hull ne doit plus regresser visuellement vers une ancienne version.

## 4.5.260 — Même flotte écran / worker
- [x] Unifier le critère de connexion de `connected_clients()` et du worker Autopilote.
- [x] Inclure les Connectors `state=connected` même si `runtime_authorized` n est pas encore persisté.
- [x] Empêcher la fin prématurée de la vague après les seuls sites `runtime_authorized=1`.
- [x] Conserver l exclusion des clients non opérationnels et des Connectors réellement déconnectés.
- [x] Conserver Recovery fail-closed et toutes les protections de déploiement.

## 4.5.259 — Autopilote jusqu au dernier site
- [x] Éviter la déduplication WordPress des événements cron de continuation avec un jeton unique par lot.
- [x] Planifier le lot suivant comme immédiatement dû avant `spawn_cron()`.
- [x] Conserver `worker_status=queued` entre les lots et réserver `idle` à la fin réelle du cycle.
- [x] Continuer même si un site est bloqué Recovery ou en erreur.
- [ ] Validation terrain : exécuter une vague complète sur les 15 sites connectés et confirmer le passage jusqu au dernier site sans nouveau clic.

## 4.5.258 — File Autopilote persistante
- [x] Continuer automatiquement au lot suivant après libération du verrou worker.
- [x] Ne plus limiter le bouton manuel à un seul site.
- [x] Ne plus recharger toute la page après le premier lot.
- [x] Rafraîchir silencieusement les lignes pendant la poursuite en arrière-plan.
- [x] Conserver Recovery fail-closed et isoler les erreurs par site.

## 4.5.257 — Recovery zero-clic
- [x] Faire de Hub Client un prerequis auto-reparable du parcours Recovery.
- [x] Eliminer le cercle Hub ancien -> Recovery impossible -> Hub impossible a mettre a jour.
- [x] Lancer automatiquement validation objective du scope + checkpoint + test fichiers/SQL depuis l Autopilote.
- [x] Reprendre Tech et les mises a jour sans clic lorsque Recovery devient pret.
- [x] Simplifier l UX : **Reparer la selection** remplace la preparation Recovery manuelle dans le parcours normal.
- [ ] Validation terrain sur Plomberie Soltech principal + /region avec preuve de reprise complete.

# Roadmap publique Suite 4.5.319 — 4.5.255

**Livré :** Synchronise /hub/roadmap avec l UX Campagnes Appels/Formulaires, le pilotage Elementor/Gravity Forms depuis Alliance et la suppression logique sécurisée des fiches clients CRM.

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

# Core AWM 4.5.254 - Autopilote Recovery auto-réparable

## Livré
- [x] Réparer/inspecter automatiquement Recovery lorsqu une mise à jour de flotte est détectée.
- [x] Relancer automatiquement le vrai test fichiers + SQL lorsque le périmètre a déjà été confirmé.
- [x] Reprendre le déploiement automatiquement dans le même passage dès que `recovery_ready_for_auto=1`.
- [x] Garder une confirmation humaine unique lorsque l absence d écrivains externes n a jamais été confirmée.
- [x] Ajouter **Préparer Recovery** pour les sites sélectionnés avec progression et poursuite malgré un site bloqué.
- [x] Relancer automatiquement l Autopilote après une préparation Recovery réussie.
- [x] Journaliser réparation, test, attente de confirmation et blocages sans masquer les erreurs Recovery.

## Validation terrain
- [ ] Sélectionner 2 à 3 sites avec `Recovery requis`, lancer **Préparer Recovery** une seule fois et confirmer que chaque site est traité indépendamment.
- [ ] Confirmer qu un site déjà approuvé mais sans test valide exécute automatiquement le test fichiers + SQL et passe ensuite sa mise à jour sans clic manuel.
- [ ] Confirmer qu un site non approuvé reste bloqué avec demande de confirmation, sans forçage.
- [ ] Vérifier le journal de sécurité et le ROADMAP public après publication Suite 4.5.318.

## Historique 4.5.253
- Transport Suite/module par paquets XHR 512 Ko, sans iframe.
- Paquet de secours ponctuel **AWM Core Packet Bootstrap** conservé pour sortir d un verrou circulaire où un ancien Core bloque sa propre mise à niveau.
- Bootstrap limité au remplacement de Core, avec manifeste SHA-256 du payload, validation de version, stage local, bascule par renommage et rollback si la bascule échoue.

# Core AWM 4.5.252 - import par paquets XHR sans iframe
- [x] Decouper les ZIP Suite/module en paquets de 512 Ko.
- [x] Envoyer les paquets uniquement par XMLHttpRequest.
- [x] Utiliser `admin-ajax.php` relatif a l origine exacte du wp-admin comme endpoint principal.
- [x] Garder un repli XHR same-page, sans iframe et sans lecture cross-origin.
- [x] Assembler cote serveur et verifier taille + SHA-256 avant import.
- [x] Conserver la limite globale de 256 Mo avec 512 paquets maximum.
- [x] Conserver nonce, validation documentaire, manifeste, depot prive et no-downgrade.
- [ ] Valider sur Alliance avec Suite 4.5.314 puis conserver ce test dans les publications suivantes.

# Core AWM 4.5.249 - transactions v3 orphelines
- [x] Detecter une transaction v3 ouverte vers une cible plus ancienne lors d un deploiement manuel.
- [x] Tenter de la finaliser puis de la commit avant toute nouvelle ecriture.
- [x] Rollback lie au `deployment_id` uniquement si la finalisation precedente n est plus possible.
- [x] Abandonner `verified`/`staged` anciens sans toucher la production apres 5 minutes.
- [x] Conserver no-downgrade, Recovery fail-closed, HMAC/SHA-256 et verification sur requete fraiche.
- [ ] Valider sur le site Vendre Maison Vite - VMV-GADS bloque par `awm_deploy_resume_target_conflict` avant de generaliser a l Autopilote.

# Core AWM 4.5.248 - Simplification Hub Client
- [x] Revenir a un Hub Client WordPress classique comme etat normal unique.
- [x] Ne plus exiger AWM System Agent dans la preuve de sante Hub 1.14.2+.
- [x] Harmoniser la flotte par lots de 4 et continuer si un site echoue.
- [x] Utiliser Tech/System Agent uniquement comme secours de transition si Hub est indisponible.
- [x] Nettoyer les anciens artefacts AWM MU seulement apres preuve `classic_mode + boot_ok`.
- [x] Conserver SHA-256, HMAC, sauvegarde/rollback v3, no-downgrade, site_id et permissions.
- [ ] Apres harmonisation terrain, retirer le code de compatibilite MU devenu inutile.

# Core AWM 4.5.247 - Réharmonisation flotte
- [x] Réparer les sites déjà équipés de System Agent.
- [x] Mettre à niveau les anciens Hub encore joignables vers 1.14.1.
- [x] Laisser Hub 1.14.1 auto-semer System Agent 2.0.1.
- [x] Utiliser Tech Rescue uniquement pour réactiver un Hub existant avant mise à niveau.
- [x] Continuer la vague même si certains sites restent bloqués.
- [x] Exiger Hub 1.14.1 + safe_legacy + boot_ok + System Agent comme preuve finale.
- [ ] Étendre cette mécanique aux autres modules après stabilisation terrain.

# Core AWM 4.5.246 - Patch flotte Hub sécurisé

- [x] Patch Hub flotte System-Agent-only depuis le central.
- [x] Lots de 2 sites et progression visible.
- [x] Confirmation obligatoire `safe_legacy` + `boot_ok` par site.
- [x] Aucun repli ancien Rescue/Tech pendant la vague.
- [x] Arrêt automatique après 3 échecs consécutifs.
- [x] Sites bloqués laissés intacts et journalisés.
- [ ] Retirer le mode safe_legacy seulement après stabilisation terrain multi-sites.
- [ ] Étendre System Agent aux déploiements Tech/Studio après validation terrain.

# Core AWM 4.5.245 - System Agent fail-safe

- [x] Canal de secours MU indépendant de Hub Client.
- [x] Installation Hub Client signée et SHA-256 via System Agent.
- [x] Activation dans une requête séparée et vérification `safe_legacy`/`boot_ok`.
- [x] Arrêt fail-closed si l agent système répond mais ne peut pas réparer.
- [x] Plus aucun cutover MU automatique pour Hub Client 1.14.0+.
- [x] Conserver Recovery/autopilote fail-closed.
- [ ] Étendre System Agent aux déploiements Tech/Studio après validation terrain Hub.

# Core AWM 4.5.244 — stabilité flotte avant remise en MU

- [x] Exiger une preuve `rescue_legacy` avant de remplacer un Hub Client non-MU-complet.
- [x] Bloquer AVANT écriture si le garde MU ne peut pas être confirmé.
- [x] Supprimer le double pré-armement dans le parcours Réparer.
- [x] Conserver Recovery fail-closed et les preuves de transaction v3.
- [ ] Après restauration complète de la flotte, ajouter une action séparée « Remettre en MU » avec autorisation courte et preuve de requête fraîche.

# Core AWM 4.5.243 — restauration de flotte avant remise en MU

- [x] Pré-armer un garde MU avant la mise à jour Hub Client lorsque la migration courante est incomplète.
- [x] Accepter une preuve `rescue_legacy` uniquement sur intervention administrateur manuelle.
- [x] Fermer proprement la transaction Hub Client sans prétendre que MU est complet.
- [x] Permettre ensuite la poursuite des mises à jour Tech AWM.
- [x] Garder l Autopilote fail-closed pendant le mode de secours.
- [ ] Valider Allo Déménagement principal puis ALLO-DEM-GADS.
- [ ] Après stabilisation, ajouter une action contrôlée de remise en MU site par site avec preuve sur nouvelle requête.
- [x] Supporter le test Recovery SQL sur hebergement mutualise sans privilege CREATE DATABASE via sandbox de tables isolees.


## Livré 4.5.267
- Repli multi-transport signé pour les derniers sites dont le WAF/proxy refuse certains endpoints WordPress.


## Livré 4.5.268
- [x] Transport statique éphémère de paquet pour les réparations/déploiements manuels afin de contourner les réponses ZIP vides et HTTP 503.
- [x] Validation locale taille + SHA-256 avant exposition temporaire du ZIP.
- [x] Conservation des transports admin-post, REST, admin-ajax et frontal comme replis.
- [ ] Futur : réintroduire Recovery comme certification asynchrone indépendante qui ne bloque jamais l’Autopilote principal.


## Livre 4.5.269
- [x] Cadence Autopilote a 1 site par lot.
- [x] Delai inter-site pour eviter les rafales.
- [x] Verrou d inventaire par site et deduplication multi-onglet/worker.
- [x] Polling navigateur sequentiel sans chevauchement.
- [x] Decode JSON resilient aux parasites serveur.

## 2026-10-21 — Design Composer v2
- Livré : familles typographiques, surfaces indépendantes, mouvement contrôlé.
- Futur : iconographie par famille, personnalité KPI/tableaux, score qualité du thème, QA combinatoire automatisée.

## 2026-10-21 — Core 4.5.318
- [Livré] Pont autoritaire Design Composer pour la route Hub AWM > Clients, avec fallback serveur + JS et protection des cartes client.
### 4.5.319 — Autorité Light/Dark inter-routes
- Synchronisation unique du mode thème Core sur Hub Clients legacy.
- Garde CSS contre une branche Light gagnante en présence d un marqueur Dark.