← Roadmap publique
README
Core AWM V4.5.214Snapshot sécurisé de la version effectivement publiée. Les lignes potentiellement sensibles sont masquées automatiquement.## Core AWM 4.5.214 Le déploiement distant manuel est de nouveau disponible depuis le tableau de bord. Les actions explicites **Déployer** et **Forcer sur la sélection** restent protégées par le canal signé et le rollback fichiers du Hub Client; l'autopilote reste suspendu jusqu'à validation Recovery complète. ## 4.5.213 - Flotte lisible et etat autopilote coherent - 2026-09-21 La grille Sites connectes reserve desormais 360 px aux actions Reparer / Voir / Deployer. Les boutons ne peuvent plus recouvrir les colonnes Statut ou Mises a jour; si l espace manque, seul le tableau flotte defile horizontalement. L interface indique maintenant **Autopilote flotte suspendu**, en coherence avec le garde Core qui maintient le deploiement automatique desactive tant que Recovery complet n est pas valide. ## 4.5.212 - Tableau de flotte stable visuellement - 2026-09-21 La liste **Sites connectes** garde maintenant ses colonnes alignees pendant et apres les mises a jour. Les actions ne recouvrent plus Statut ou Mises a jour. Sur une largeur insuffisante, le tableau conserve sa geometrie et utilise le defilement horizontal de la zone de flotte. ## 4.5.211 - Selection flotte fiable - 2026-09-21 Core AWM restaure la selection globale des Hub Clients dans **Mises a jour -> Sites connectes**. Le bouton **Tout selectionner** et la case maitre selectionnent tous les sites visibles; le libelle passe automatiquement a **Tout deselectionner** lorsque la vue courante est entierement selectionnee. Le correctif remet aussi l initialisation JavaScript dans le bon ordre afin que le transport de ZIP par blocs 4 Mo et les actions de flotte puissent coexister sans interrompre le script de la page. ## 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. - 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 - **Livré** : registre public aligné sur Tech AWM 1.7.31 et Suite AWM 4.5.228. - **Livré** : règle `AWM-TECH-OPS-PRIORITY-001` pour un score opérationnel explicable, des actions recommandées sûres et l historique 24 h / 7 j sans duplication Stats. - **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 de Suite AWM 4.5.219. Cette version publie Tech AWM 1.7.22 et formalise la règle UX sans rechargement complet pour les actions compatibles AJAX. Cette version met à jour le registre de publication pour Suite AWM 4.5.218 et Tech AWM 1.7.21. Aucun contrat Connector, CRM ou autopilote n est modifié. # Core AWM 4.5.188 Cette version publie Tech 1.7.20 et CRM 1.6.26 afin de rendre les statuts des fiches multi-sites directement actionnables, sans modifier l identité client/site ni la sécurité Connector. Cette version aligne automatiquement la roadmap publique sur la **Suite active**. La dernière implantation n est plus une ligne Core codée en dur : elle reprend `roadmap_sync` et la composition effective publiée. # Core AWM 4.5.186 Core ajoute un **autopilote central de flotte** : une fois une Suite stable publiée, Core parcourt automatiquement les installations Hub Client réellement jumelées et applique les mises à jour Hub Client/Tech nécessaires sans sélection manuelle. Les sites sont traités par petits lots afin de limiter la charge. Les déploiements manuels restent disponibles uniquement comme forçage. Core 4.5.184 publie Tech AWM 1.7.16 et garde le registre de Suite aligné sur la nouvelle fiche Tech en console opérationnelle. Aucun changement de contrat Connector ou d autopilote n est introduit. Ajoute la visibilité de l autopilote Hub Client 1.11.42+ pour les mises à jour client Hub/Tech. # Core AWM 4.5.182 Registre Suite aligné sur Tech AWM 1.7.15; Hub Client 1.11.41 reste la base d autopilote. # Core AWM 4.5.181 Cette version aligne Core sur la maintenance automatisée de la flotte Hub Client et Tech. Hub Client 1.11.41 peut appliquer ses futures versions stables depuis le canal signé Core après appairage, tandis que Tech 1.7.14 pilote séparément les extensions WordPress tierces choisies par le technicien. Les modules AWM ne passent jamais par le moteur générique d extensions. ## Core AWM 4.5.179 — liaison Hub robuste et shell plus compact Core normalise maintenant l alias conventionnel `www`/domaine nu pour la liaison Hub Connector tout en gardant les autres sous-domaines et chemins stricts. Le shell partagé accepte aussi des métadonnées de contexte compactes directement dans son en-tête. ## Core AWM 4.5.178 — shell AWM sans bandeaux WordPress Toutes les pages dont le slug appartient à l'espace AWM (`awm-*` / `awm_*`) sont maintenant protégées par le masque global de notices. Les résultats métier doivent utiliser le loader AWM; les avis WordPress et tiers ne doivent plus casser le layout des modules. # Core AWM 4.5.177 — contrat Screpy pour Stats / Health Core 4.5.177 formalise `AWM-STATS-009`. Screpy devient la couche d observation technique externe pour Stats / Health AWM : crawl SEO, Quick Wins, Rank Tracker, Core Web Vitals et uptime. La clé API Alliance reste côté serveur et doit être chiffrée avec `AWM_Core_Vault`. Le périmètre AWM reste `client_id + site_id + instance_uuid`; le domaine sert uniquement à associer le projet Screpy au site runtime. Health interprète les signaux et Studio réalise les corrections. --- # Core AWM 4.5.176 — carte Stats Light/Dark et progression stable Core 4.5.176 ajoute `AWM-STATS-008` pour garantir que la carte Temps réel suit réellement le thème AWM, corrige la détection `awm-theme-dark` et supprime le pixel fantôme des barres de progression à 0 %. Core 4.5.175 ajoute `AWM-STATS-007` : la carte Temps réel de Stats doit avoir un mode par défaut utilisable sans compte ni clé API cartographique. Stats AWM 1.6.1 utilise OpenStreetMap standard et dérive localement son rendu sombre; une panne du fond de carte ne doit jamais interrompre les présences, KPI ou listes en direct. Core 4.5.174 formalise `AWM-STATS-006` (carte temps réel résiliente sans GPS/IP) et `AWM-UX-003` (les rafraîchissements techniques de fond ne déclenchent jamais le loader global). Core 4.5.173 étend l horloge canonique `America/Toronto` déjà introduite en 4.5.153 : les modules peuvent maintenant obtenir des bornes de périodes UTC correspondant exactement aux journées civiles de Montréal. Le stockage reste UTC et HAE/HNE est géré automatiquement. Stats AWM 1.5.1 utilise ce contrat pour ses timestamps visibles et ses séries quotidiennes. Core 4.5.172 conserve le registre commun introduit en 4.5.171 et formalise le temps réel Stats. Le registre des Connectors Hub Client runtime réellement actifs permet à Stats/Health et Mises à jour d’utiliser la même définition d’un site connecté : le `client_id` est le client attitré, le `site_id` est la source exacte, et un site CRM sans autorisation runtime reste hors du périmètre actif. Le contrat API Stats `site_id` + 365 jours de 4.5.170 est conservé. # Core AWM 4.5.168 — mémoire auto-réparable et diagnostic visible Core 4.5.169 limite désormais **Mises à jour → Sites connectés** aux Connectors runtime réellement appairés. Les sites CRM non liés restent gérés dans CRM et ne sont plus présentés comme des cibles de déploiement. Un filtre Principal/Secondaire facilite les parcs multi-sites. Core 4.5.168 remplace les réparations heuristiques des versions précédentes par une restauration canonique strictement limitée aux révisions `v1` créées par Core (`author_id=0`) et présentes dans le seed officiel AWM. Lorsqu une de ces révisions a une empreinte invalide, les champs couverts par le SHA sont reconstruits depuis le seed; le statut, les dates, le cycle de vie, les révisions `v2+` et toutes les règles utilisateur restent intacts. La santé de la mémoire relance la réparation avant de compter les anomalies. **Core → Mémoire AWM** affiche aussi la version de schéma mémoire, la version du seed, la dernière tentative UTC, le nombre réparé et le nombre restant. Un outil de récupération autonome peut être utilisé ponctuellement si le runtime Core chargé est bloqué par un cache serveur ou un ordre de chargement historique. # Core AWM 4.5.166 — réparation SHA canonique Mémoire AWM Core 4.5.166 remplace la migration de réparation 4.5.165 par une stratégie fondée sur l empreinte canonique du seed. Une révision v1 système n est réparée que si son SHA stocké prouve qu elle provient exactement du seed officiel. La réparation est réessayée avant le préflight et ne se déclare terminée qu à **0 anomalie réelle**. Un bouton de réparation manuelle sûre est aussi disponible dans **Core → Mémoire AWM → Santé**. # Core AWM 4.5.165 — intégrité Mémoire AWM réparée Core 4.5.165 corrige le faux positif d intégrité qui marquait les 50 règles initiales de Mémoire AWM comme critiques. Le contrôle d intégrité reste strict : seule la signature exacte du défaut historique `change_reason` des seeds système est réparée automatiquement. Les altérations inconnues restent bloquantes. # Core AWM 4.5.164 — déploiement distant réellement multi-sites Core 4.5.169 consolide le passage de l'écran **Mises à jour** au contrat `client_id + site_id`. Un client possédant un site principal et plusieurs sites secondaires obtient maintenant une ligne par site. Chaque inventaire, commande distante, paquet signé, vérification et rollback cible le Connector du site choisi. Le site principal conserve ses métadonnées historiques pour compatibilité, mais aucune action sur un site secondaire ne réutilise son secret de scan ni son inventaire. Les sites connus du CRM peuvent être visibles avant connexion complète afin qu'un administrateur voie immédiatement ce qui reste à appairer. # Core AWM 4.5.163 — import robuste + Mémoire AWM mini-Git ## Correctif 4.5.163 — noms de ZIP dupliqués Les navigateurs peuvent renommer un second téléchargement `core-awm-4.5.162 (1).zip`; après normalisation WordPress, ce nom devient `core-awm-4.5.162-1.zip`. Les versions précédentes pouvaient interpréter `-1` comme une préversion et refuser le paquet même si le plugin déclarait correctement `4.5.162`. Core distingue maintenant les suffixes de copie numériques des vraies préversions et conserve la validation stricte du numéro interne. ## Mémoire AWM — mini-Git interne Core 4.5.162 ajoute une mémoire de développement persistante dans WordPress. Elle est conçue pour survivre aux changements de conversation et pour transporter les décisions importantes du projet dans le temps. - historique append-only : aucune ancienne version n est réécrite; - IDs stables comme `AWM-DEV-003` ou `AWM-MULTI-001`; - statuts `active`, `review`, `draft`, `superseded`, `archived`; - SHA-256 du contenu de chaque révision; - auteur, date, parent, source et raison du changement; - liste explicite des modules impactés; - détection de conflit si une règle a évolué pendant qu une autre conversation travaillait; - restauration par création d une nouvelle version; - snapshots automatiques lors des publications de Suite; - export JSON administrateur; - santé de mémoire et détection des anomalies structurelles; - refus des secrets avant enregistrement. L écran se trouve dans **Core AWM → Mémoire AWM** et un résumé est visible dans le tableau de bord Core pour les administrateurs. Le seed initial reprend uniquement le contexte AWM pertinent accumulé dans les développements : architecture, publication, multi-sites, Studio, Stats/Health, Connectors, UX et sécurité. Les données personnelles et souvenirs sans lien avec AWM sont volontairement exclus. ### Utilisation par les autres modules `AWM_Core_Development_Memory::active_rules()` permet de demander uniquement les règles pertinentes pour un ou plusieurs modules/catégories. Cette approche évite de charger toute la mémoire dans les prompts IA et applique la règle **local d abord → contexte filtré → IA seulement si nécessaire**. ## Correctif 4.5.161 Sur certaines installations historiques, le registre SQL peut continuer à refuser la création d'un deuxième Connector même après suppression des anciens index et reconstruction canonique. Core 4.5.161 ne bloque plus le site dans ce cas : il conserve le contrat `client_id + site_id + instance_uuid` et bascule uniquement ce Connector vers un stockage de secours client-scoped basé sur les métadonnées WordPress. Le record logique reste identique au record SQL. Les hashes de pairing et de runtime sont indexés par des options non-autoloadées afin que l'authentification Connector reste directe et n'exige aucun scan global. Les mêmes fonctions Core alimentent ensuite Hub Client, Stats, Health et Tech, quel que soit le backend de stockage du site. Aucun secret n'est exposé au navigateur, aucun Connector principal n'est révoqué, et aucune donnée historique Stats/Health n'est supprimée. Si le registre SQL redevient sain plus tard, une migration vers SQL pourra être ajoutée sans changer le contrat public du Connector. ## Historique 4.5.160 — reconstruction canonique Connector multi-sites ## Correctif 4.5.160 Certaines bases historiques peuvent encore refuser la création d'un second Connector même après suppression des anciens index `UNIQUE`. Core 4.5.160 ajoute une seconde ligne de défense : si l'insertion échoue encore, le registre `awm_site_connectors` est recopié dans une table neuve construite exactement selon le schéma multi-sites courant, puis remplacé atomiquement. Cette reconstruction retire les colonnes/contraintes historiques que `dbDelta()` laisse parfois en place, tout en conservant les données Connector actuelles et sans régénérer de secret. Le contrat reste `client_id + site_id + instance_uuid`. Le site principal et les sites secondaires restent isolés; la reconstruction ne modifie ni les rattachements CRM ni l'historique Stats/Health. ## Correctif 4.5.159 Core vérifie et répare le schéma du registre `awm_site_connectors` avant de créer un Connector secondaire. Les bases ayant conservé un ancien index `UNIQUE` incompatible avec plusieurs sites par client sont corrigées automatiquement. Le contrat reste `client_id + site_id + instance_uuid`; aucun Connector existant n’est révoqué et aucun secret n’est régénéré par la migration. Les échecs persistants sont classifiés dans le journal Core sans stocker la requête SQL ni les valeurs sensibles. Core ajoute un canal de collecte Stats authentifié pour Hub Client. Chaque lot reçu est validé contre le registre multi-sites Core (`client_id`, `site_id`, URL et `instance_uuid`) puis délégué à Stats AWM. Le canal suit les mêmes protections Connector et transports de secours que le reste de la plateforme sans modifier les secrets existants. Cette identité site-scoped permet à Stats et Health de consolider tous les sites d’un client tout en conservant la source exacte de chaque KPI. # Core AWM 4.5.157 — composition anti-rétrogradation et réconciliation dépôt ## Correction critique 4.5.157 Core 4.5.156 possédait encore deux bootstraps historiques destinés à amorcer Studio 1.14.0 et Tech 1.6.8 lorsqu ils étaient absents. Leur enregistrement dans la publication active ne vérifiait pas la version déjà effective. Après une promotion directe, un chargement admin pouvait donc réécrire silencieusement Studio 1.16.0 vers 1.14.0 ou Tech 1.6.9 vers 1.6.8. Core 4.5.157 rend ces bootstraps strictement anti-rétrogradation et ajoute une réconciliation idempotente entre le dépôt central et la publication active. Une version strictement supérieure déjà importée est automatiquement repromue avec les mêmes contrôles Vault, SHA-256, roadmap et historique que l import direct. ## Import rapide unifié 4.5.156 La zone d import de la carte « Publication active » accepte maintenant aussi bien une Suite complète qu un ZIP de module autonome. Core identifie le paquet par sa convention de nommage, puis utilise exactement le même validateur spécialisé que les formulaires avancés. Un module supérieur peut donc être importé et promu sans reconstruire toute la Suite. - La roadmap publique peut maintenant servir de point de départ de review entre conversations grâce aux snapshots de documentation de la version effective. - Core conserve les paquets chiffrés et ne rend public que le texte filtré de README.md, CHANGELOG.md et ROADMAP.md. # Core AWM 4.5.154 — dépôt de modules + composition de Suite Core AWM 4.5.154 sépare maintenant les versions de modules des snapshots Suite. Un administrateur peut importer directement un ZIP de module dans un dépôt privé chiffré; les nouveaux imports directs doivent conserver `README.md`, `CHANGELOG.md` et `ROADMAP.md`. Lors de la publication d une Suite, Core vérifie d abord la cohérence interne du ZIP puis conserve automatiquement toute version supérieure déjà disponible dans le dépôt ou dans la publication active. Aucun downgrade automatique n est permis. Les imports directs peuvent être promus immédiatement dans la publication active lorsqu ils sont supérieurs. Chaque promotion met à jour `roadmap_sync.versions`, ajoute un avancement Livré issu de la roadmap du module, conserve une entrée `composition_revisions` et écrit dans le journal de sécurité. Les erreurs de validation sont également journalisées. Le stockage des paquets reste privé, chiffré et contrôlé par SHA-256. # Core AWM 4.5.153 — heure Alliance canonique Suite 4.5.153 corrige les horodatages de l administration Alliance : stockage UTC, affichage `America/Toronto` avec HNE/HAE automatique, historique des publications reconstruit depuis les identifiants UTC et Tech AWM 1.6.8 aligné sur la même horloge. La télémétrie multi-sites 4.5.152 reste inchangée. # Core AWM 4.5.147 Suite 4.5.147 publie **CRM AWM 1.6.19**. La fiche client multi-sites reçoit une interface premium responsive, un `site_type` canonique distinct de l'environnement technique et des actions directes Ajouter / Promouvoir / Supprimer. Tech AWM reste en 1.6.6 et continue de consommer le même `client_id` / `site_id`. Suite 4.5.146 publie **CRM AWM 1.6.18** et **Tech AWM 1.6.6**. La fiche client canonique supporte maintenant un site principal et des sites secondaires; le site principal reste la source de vérité visuelle et Tech affiche chaque site séparément avec son rôle et son état de connexion. # Core AWM 4.5.145 Suite 4.5.145 publie Tech AWM 1.6.5 et Hub Client 1.11.32. Le centre Tech peut maintenant relire les inventaires des sites à la demande via le canal privé Hub Client et exécute un scan central horaire pour faire ressortir les nouvelles correspondances critiques du journal de vulnérabilités. Aucune API payante n est ajoutée. Cette livraison publie Tech AWM 1.6.4 et fait progresser le centre d opérations Alliance avec un inventaire logiciel détaillé, la comparaison des versions Suite AWM et un journal de vulnérabilités WordPress basé uniquement sur Wordfence Intelligence V3 gratuit. La clé gratuite est conservée côté Alliance dans le coffre Core et le flux est mis en cache centralement afin de limiter les appels. Le bootstrap Tech est maintenant aligné sur 1.6.4 : paquet, cible et SHA-256 correspondent. Cette livraison publie Tech AWM 1.6.3 et conserve Hub Client 1.11.31. Elle améliore la personnalisation de la fenêtre Tech sans toucher au moteur d intervention : opacité des fonds indépendante du texte et des bordures, choix de police, couleur d accent et presets persistants. Les actions de page restent bornées par la session Alliance, les permissions et le post ciblé. Les écritures Elementor conservent snapshot et hash de concurrence; le repli CSS frontend est limité à une liste de propriétés sûres et peut être restauré par le rollback Tech. # Core AWM 4.5.140 Cette livraison corrige la boucle Elementor Loading / Safe Mode : Tech AWM 1.5.17 isole totalement l iframe elementor-preview du bootstrap front-end Tech. La boîte privée Alliance conserve le thème terminal Matrix et se monte uniquement dans l éditeur. Cette livraison durcit le déploiement Tech site par site. Core effectue d abord la mise à jour normale; si Tech reste plus ancien ou si la preuve runtime/Elementor ne revient pas, une seule réparation propre est déclenchée via Hub Client 1.11.28, puis une nouvelle vérification serveur confirme le résultat. # Core AWM 4.5.131 Cette version corrige le 404 observe lors de `Tech AWM → Sites → Elementor`. La disponibilite de la route privee fait maintenant partie de la preuve de readiness distante, au meme titre que la version Tech reellement chargee. # Core AWM 4.5.129 Cette version fiabilise le lancement Tech → Elementor par un **handoff serveur-à-serveur**. Core demande au site Hub Client de préparer la session, de résoudre la page en `post_id` et de retourner une URL Elementor privée. Hub Client 1.11.25 remonte ensuite la version Tech réellement chargée en PHP et invalide OPcache après les déploiements, ce qui empêche une ancienne copie runtime de masquer le nouveau code. # Core AWM 4.5.127 Cette version corrige une incohérence de packaging de la Suite 4.5.126 : le ZIP Core et le manifeste principal étaient en 4.5.126, mais `roadmap_sync.versions.core` et `roadmap_sync.versions.suite` étaient restés en 4.5.125. Le contrôle strict de Core a donc correctement refusé l import. La Suite 4.5.127 est reconstruite à partir des versions réelles des dix paquets afin que ZIP, manifeste et roadmap soient identiques avant distribution. # Core AWM 4.5.126 Cette version publie Tech AWM 1.5.9 et accélère le parcours d intervention Elementor. Si un site client possède une version Tech plus ancienne, le clic d intervention utilise automatiquement le paquet Tech de la publication active, vérifie la version réellement installée puis ouvre Elementor avec l unique boîte Tech privée. Le technicien n a plus à quitter Tech AWM pour déployer manuellement la version requise. # Core AWM 4.5.124 ## Stabilisation et cadence de développement Cette version publie Tech AWM 1.5.7 et corrige l affichage du dernier contact Tech : stockage UTC, affichage dans le fuseau WordPress Alliance. Elle conserve la stabilisation Elementor de Tech 1.5.6 et aligne aussi le bootstrap Core sur Tech 1.5.7 et privilégie la fiabilité de l intervention Elementor. Les ouvertures d intervention sont prévalidées, la session est visible, la prévisualisation est attendue automatiquement et le registre roadmap est synchronisé avec la vraie version Tech. La cadence de développement devient volontairement plus courte : un objectif principal par livraison, contrôle statique, validation terrain explicite et revue systématique des éléments à conserver dans **Futur**. # Core AWM 4.5.105 — UX compacte et accès roadmap Core 4.5.105 optimise l’onglet **Mises à jour** sans changer son moteur de déploiement. Le grand espace vide sous le titre est supprimé : les KPI de version, mises à jour Alliance, sites connectés et déploiement distant occupent maintenant directement la zone de gauche, tandis que la publication active et l’import de Suite restent à droite. La zone centrale affiche maintenant un accès Premium direct à la roadmap publique AWM. La liste des sites utilise une grille compacte et ajoute **Réparer** lorsqu’un inventaire Hub Client est absent. Cette action retente immédiatement le canal sécurisé Connector et met à jour l’inventaire; en cas d’échec, le détail du site affiche la raison exacte au lieu de laisser un état ambigu. La source client reste CRM AWM, le déploiement reste signé/chiffré et Core continue de traiter sa propre mise à jour en dernier. ## Tech AWM 1.5.2 Core publie Tech AWM 1.5.2. La section **Tech AWM → Sites** est maintenant visible dans le shell administratif et devient la vue d’entrée par défaut. Elle liste les sites Hub Client confirmés par l’inventaire Core et permet une intervention directe sans dupliquer les fiches CRM. Tech AWM 1.5.18 conserve une intervention Alliance active pendant la navigation wp-admin et Elementor, avec personnalisation locale de la fenêtre terminale. ## Tech AWM 1.6.0 Core 4.5.139 publie le dashboard Tech source-first et l intervention frontend directe. La navigation Tech principale reste dans le menu WordPress; les cartes ouvrent des popups contextuelles vers leurs sources. Les donnees de monitoring non encore sondees ne sont pas simulees. ## Contrat temps réel Stats 4.5.172 Le canal Connector Stats existant accepte désormais le heartbeat `presence` traité par Stats AWM. Core conserve l'authentification exacte `client_id + site_id + instance_uuid`; aucun secret, IP ou GPS n'est exposé au navigateur ou stocké par Core. ## 4.5.185 Core publie Tech AWM 1.7.17 et garde le registre de flotte aligné sur la carte Centre opérations compacte.