README

# Core AWM 4.5.328

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

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

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

---

# Core AWM 4.5.327

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

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

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

---

# Version 4.5.326

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

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

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

---

# Core AWM 4.5.325

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

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

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

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

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

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

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

---

# Core AWM 4.5.324

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

## Validation et portée

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

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

---

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

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

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

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

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

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

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

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

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

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

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

## Mise à jour 4.5.322 — 2026-10-21 · Suite 4.5.463

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

## Core AWM 4.5.306 - Version source cohérente

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

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

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

## Core AWM 4.5.304 - Visual QA multi-onglets

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

## Core AWM 4.5.303 - Contraste hover Dark

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


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

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

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


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

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

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

## Core AWM 4.5.300 - Design System & QA

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


## Core AWM 4.5.299 - Sweep final sans arrondis

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

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

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

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

## Core AWM 4.5.297 - Design System Square Blue

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

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

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

# Core AWM 4.5.294 — Affichage commun AWM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Candidate de migration additive : tests locaux, essai WordPress/MySQL et sites clients requis.
Aucun transfert a l'installation. Ne supprime ni sources historiques, ni audio Twilio.
Un seul lancement global depuis CRM AWM > CRM Clients - campagnes et leads.
Prealables : trousseau Core enrole et sauvegarde separement; Hub Client 1.14.22 sur sources et destination; autorisations techniques.
Le statut commercial et le statut des campagnes ne sont pas modifies. Capturia n'est jamais exige ni active pour les autres clients.

---

# Core AWM 4.5.286 - Correctif acces aux pages secondaires

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

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

---

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

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

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

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

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

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

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

---

## Historique conservé

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

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

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

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

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

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

---

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

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

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

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

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

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

# Core AWM 4.5.277 — roadmap publique CallTracker 1.11.30

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

# Core AWM 4.5.276 — roadmap publique CallTracker 1.11.29

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

# Core AWM 4.5.275 — roadmap publique CallTracker 1.11.28

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

# Core AWM 4.5.274 — roadmap publique CallTracker 1.11.27

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### File Autopilote persistante — Core 4.5.258

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

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

# Hub Core 4.5.255 — Roadmap publique Suite 4.5.319

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

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

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

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

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

# Core AWM 4.5.252 - import par paquets XHR sans iframe

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

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

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

# Core AWM 4.5.249 - reprise automatique des transactions v3 supersedees

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

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

# Core AWM 4.5.248 - architecture Hub simplifiee

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

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

# Core AWM 4.5.247

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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


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


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

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


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

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