← Roadmap publique
CHANGELOG
Core AWM V4.5.328Snapshot sécurisé de la version effectivement publiée. Les lignes potentiellement sensibles sont masquées automatiquement.# 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 Reparer / 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.