← Roadmap publique
ROADMAP
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. ## Futur examiné Trois nouvelles pistes sont différées : provenance du visuel, lisibilité du logo sur les deux fonds et comparaison des icônes à leur taille réelle. Les propositions précédentes restent tracées; aucun nouvel outil de génération ou de retouche de marque n’est livré dans cette correction. --- # Core AWM 4.5.327 Suite AWM 4.5.469 — Aperçu avant enregistrement · 22 octobre 2026. Publie les recettes de prévisualisation canoniques et ajoute dans Design System & QA le parcours URL → brouillon → aperçu clair/sombre → approbation explicite → application comme défaut client. Les actions utilisent les permissions Core/CRM et des nonces; aucun modèle n’est approuvé automatiquement. Le registre conserve des configurations contrôlées et leur empreinte; la bibliothèque réutilise ou télécharge les fichiers de police manquants, avec variantes et origine. La mémoire ajoute deux décisions en conservant les 142 règles précédentes. Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.469.md. Les essais utilisent le code PHP/CSS/JavaScript réel avec services WordPress substitués; ils ne valent pas installation ou validation sur le site de production. ## Futur examiné Les trois nouvelles pistes de la revue 469 sont différées. Les autres propositions et leur historique restent ci-dessous; la démonstration locale du formulaire Apparence est désormais livrée, sans préjuger d’une prévisualisation de tous les écrans métier. --- ## 4.5.326 — 2026-10-22 Suite AWM 4.5.468 — Bascule clair/sombre et profils distincts. Le contrat d’apparence valide les deux profils avant toute écriture. Une bascule seule enregistre uniquement le choix Auto/clair/sombre et préserve les profils et l’identité automatique. Le raccordement administratif applique les variables et les classes du profil correspondant au mode Core. La mémoire consigne la décision et conserve les 141 entrées antérieures. Les contrôles exécutés et leurs limites figurent dans VALIDATION-SUITE-AWM-4.5.468.md. Aucune installation ni publication de cette version sur l’hébergement n’est présumée. --- ## Livraison 4.5.325 — Suite 4.5.467 L’utilisateur a accepté la Suite **4.5.466** comme référence d’apparence puis demandé l’inscription de cette décision dans la mémoire Core, les journaux et les roadmaps. La décision `AWM-APPEARANCE-BASELINE-466-001` est ajoutée au seed `2026-10-22.4`; les 139 entrées antérieures restent identiques. Les cartes et fiches administratives CRM et Hub conservent les couleurs et les six axes du client, avec la variante claire/sombre du Core de l’opérateur. Hub Client conserve indépendamment **Automatique · logo puis site**, **Toujours sombre** ou **Toujours clair**. La personnalisation manuelle reste prioritaire sur la réanalyse; l’affichage administratif n’écrit aucun choix client. Le lot officiel de migration mémoire de 4.5.466 garde son identifiant immuable `2026-10-22.3`, distinct de la version du seed courant. Un site qui passe directement de 4.5.465 à cette version peut donc encore appliquer ses révisions officielles bornées, avec les mêmes empreintes autorisées et protections des révisions humaines. La nouvelle décision est insérée par le mécanisme de mémoire existant et ses événements de journalisation habituels. La création de styles depuis une URL dans **Core → Design System & QA** reste proposée et différée. L’acceptation de la livraison ne constitue ni une installation sur l’hébergement ni une validation en production. Les résultats locaux de cette Suite sont documentés dans son rapport de validation. ## Accès au Hub Client depuis la fiche CRM La décision `AWM-CRM-HUB-SITE-USERS-001` précise le bloc permanent **Hub Client & connexion** rendu par Hub 4.5.110 dans la fiche CRM. Quand le site principal est lié par un Connector runtime autorisé, ses comptes WordPress apparaissent avec leurs cases de sélection. Le scan et l’enregistrement utilisent l’annuaire et l’allowlist existants de Core, avec leurs permissions, le nonce CRM et le périmètre explicite du site principal. Un simple affichage ou scan n’accorde aucun accès. Les références invalides et les sélections fondées sur un annuaire périmé sont refusées. Les cases utilisent les références stables Core; une modification réelle des droits réutilise la révocation des sessions API du site concerné et les journaux Core existants. Le raccourci **Hub Client** ouvre le portail du site appairé dans un nouvel onglet, en conservant le sous-dossier WordPress et l’authentification ou la session existante. Il ne crée pas de nouveau SSO. Les deux nouvelles décisions portent la mémoire à **141 clés uniques**, sans modifier les 139 entrées de 4.5.466. Core reste l’autorité des droits et du transport; cette interface est fournie par Hub. --- ## Livraison 4.5.324 — Suite 4.5.466 Core choisit la variante claire ou sombre des cartes et fiches administratives explicitement marquées, en conservant leurs couleurs et leurs six axes client. La synchronisation se fait dès le rendu et lors des bascules, sans écriture de préférence client. Les règles du shell respectent ces zones personnalisées. Les règles officielles de mémoire concernées évoluent par révisions bornées et vérifiées; les révisions humaines sont préservées. ## Validation et portée Cette version fait partie de Suite AWM 4.5.466. Les preuves détaillées sont dans `PREUVES-VALIDATION-SUITE-AWM-4.5.466.json` et le rapport `VALIDATION-SUITE-AWM-4.5.466.md` de la Suite. Elles couvrent le rendu PHP et Chromium, les modes opposés, les bascules, les identités distinctes et la persistance du choix du portail. Les tests s’exécutent localement avec données et services WordPress substitués; ils ne constituent pas une installation sur le site de production. Les préférences client ne sont pas modifiées par l’ouverture d’une carte ou d’une fiche administrative, ni par une bascule Core. Les anciennes notes ci-dessous restent historiques : pour cette livraison, les cartes et fiches administratives utilisent la variante Core, tandis que Hub Client conserve son choix indépendant. --- ## Revue 4.5.323 — 2026-10-22 · Suite 4.5.464 ### Maintenant Partager le payload canonique Hub Client avec le consommateur CRM, préserver la frontière CSS des deux zones personnalisées et corriger la mémoire de la décision 4.5.463. Le thème Core reste l’autorité du shell, du header et des guides. La fiche sélectionne l’apparence claire/sombre du profil client, automatique depuis logo/site ou choisie manuellement, indépendamment du mode Core. La précision finale porte sur les six choix existants : Style, Couleur, Typographie, Surface, Mouvement et Densité. En automatique, Hub rapproche chaque indice exploitable du CSS du site des options du catalogue. Neutral, Auto, Subtle et Standard sont les replis respectifs de typographie, surface, mouvement et densité lorsqu’aucun indice exploitable n’existe, notamment pour un logo seul. Les choix manuels restent prioritaires. ### Futur — deux pistes nouvelles différées **Simulation de perception des couleurs du profil** : prévisualiser le profil selon plusieurs simulations de perception des couleurs pour examiner la distinction des accents et des états, sans modifier les valeurs enregistrées ni les couleurs métier. Cette capacité est distincte des contrôles de contraste et des aperçus de mode déjà prévus. **Évolution proposée et différée — Création de styles depuis une URL dans Design System & QA**. Dans Core AWM → Design System & QA, saisir l’URL d’un site, analyser son identité visuelle et sa structure, puis proposer de nouveaux styles sous forme de tokens contrôlés. Prévisualiser chaque proposition en Light/Dark, ajuster ses paramètres, la nommer puis l’enregistrer au catalogue pour les clients après validation explicite. Évolution proposée et différée; aucune génération, activation ou publication de style n’est ajoutée dans 4.5.464. Cette piste ajoute la saisie d’une URL et la proposition de nouveaux jeux de tokens; elle complète l’éditeur de presets contrôlés, les favoris et les prévisualisations déjà prévus sans les recompter. La revue `2026-10-22.1` relit les dix modules. Trois pistes complémentaires côté Hub concernent le verrouillage sélectif des axes, la veille des changements d’identité avant adoption et le choix de la zone utile du logo pour l’analyse. Ces cinq nouveautés restent différées; la correction immédiate ne les implémente pas. Les mentions CRM = Core de la revue 4.5.322 ci-dessous sont remplacées par cette décision. ## 2026-10-21 — Core 4.5.322 / Suite 4.5.463 ### Périmètre - Documenter l’autorité du Design Composer Core sur le dossier administratif CRM. - Limiter les exceptions d’identité personnalisée aux scopes Hub explicitement autorisés. - Versionner mémoire, architecture et Futur en `2026-10-21.16`; 139 règles uniques. ### Maintenant - Exiger une preuve du chargement des CSS sur la route CRM réelle avant les mesures visuelles. - Comparer la fiche CRM au profil Core actif, en Light/Dark et sur écran étroit; vérifier les modes Standard/Avancé. - Consigner séparément les validations locales acquises, l’installation sur l’hébergement et la publication publique. ### Futur nouveau, différé - Palette de commandes contextuelles : rechercher au clavier les destinations autorisées du module et du dossier actifs, sans déclencher de mutation métier lors d’une navigation. ## 2026-10-21 — Candidate Core 4.5.321 / Suite 4.5.462 ### Périmètre de la candidate - Classement exact de la route centrale Hub avant exclusion du portail client, afin que le contexte Core charge les styles du shell et des guides dans la fiche. - Haut du shell cohérent avec le Design Composer administratif et frontière CSS de fiche conservée. - Contrat carte/fiche : même profil effectif complet, réellement compilé et appliqué. - Mémoire et architecture actualisées avec les six axes et les responsabilités Core/Hub. ### Maintenant - Vérifier le classement de route et les hooks de chargement PHP avant les contrôles du haut du shell en Light/Dark et sur écran étroit. - Comparer les six axes du profil d’une carte à ceux de sa fiche, en conservant un profil administratif distinct. - Consigner les validations locales, WordPress et publication séparément. ### Futur nouveau, non implémenté - Résolution des conflits de coédition du profil axe par axe, avant tout écrasement. ## 2026-10-21 — Candidate Core 4.5.320 / Suite 4.5.461 ### Implémentation dans la candidate - Frontière CSS explicite de la fiche client et de ses descendants; le shell administratif conserve son autorité sur le reste de la page. - Retrait des neutralisations `--client-*`, sans augmentation de la spécificité des autres sélecteurs Core. - Mémoire et architecture réconciliées avec les exceptions de carte/fiche et les familles Design Composer existantes. ### Maintenant - Vérifier en terrain le parcours Core Dark → Hub Clients → fiche → Identité visuelle, puis le retour à la liste et la bascule Light/Dark. - Consigner séparément les résultats locaux, la validation WordPress et la publication de la roadmap. ### Futur nouveau, non implémenté - Favoris personnels de combinaisons Design Composer. - Vue de lecture accessible propre à l’utilisateur, indépendante du profil client enregistré. ## 2026-10-21 — Core 4.5.317 / Suite 4.5.458 - [x] La couleur Design Composer devient l accent canonique des alias administratifs legacy. - [x] Palette de compatibilité dérivée automatiquement pour `--awm-blue-*`, `--ci-orange`, CRM, CallTracker, Tech et Hub. - [x] Les cartes Hub AWM > Clients sont exclues de la neutralisation admin et conservent leur thème client. - [ ] Terrain : vérifier Arctic Cyan + Glow, Electric Orange et Rounded Violet en Light/Dark. ## 4.5.316 — 2026-10-21 - [x] Autorité Design Composer sur les racines `#wpcontent/#wpbody/#wpbody-content` de Hub Clients. - [x] Classification liste administrative distincte du dossier identité client. - [x] État Light/Dark unifié, sans état local concurrent. - [x] Îlots carte client protégés via tokens `--card-*`. ## Livré 4.5.315 — 2026-10-21 - [x] Publie le catalogue Design Composer comme contrat partageable pour Hub AWM et Hub Client. - [x] Le payload Hub Client expose catalogue, tokens compilés, source et libellé de source du thème. - [x] Le retour au thème automatique relance réellement la détection `logo -> site Web -> thème AWM`. - [x] Hub AWM > Clients conserve le shell administratif central tandis que les cartes clients peuvent prévisualiser leur profil propre. - [x] Ajoute les règles de mémoire sur auto-identité, propagation du catalogue, scope de thème des services client et cartes de prévisualisation. ## 4.5.314 - Carte de message harmonisee au Design Composer - Maintenant : supprimer le fond bleu fixe du dialogue global. - Maintenant : reprendre surface, titre, texte, bordure, rayon et ombre du theme actif. - Maintenant : conserver le backdrop discret de 4.5.313 sans augmenter sa teinte. ## 4.5.313 - Backdrop theme subtil - [x] Revenir au blur historique de 3px. - [x] Limiter la teinte theme a 8 % Light / 12 % Dark. - [x] Retirer la saturation et la bordure fortement accentuee. - [ ] Futur : intensite gouvernee, adaptation par luminance, QA comparee et mode reduction de transparence. ## 4.5.312 - Couverture roadmap source + backdrop du loader - Maintenant : exiger une entree roadmap versionnee pour chaque module source modifie. - Maintenant : backdrop des messages AWM teinte par l accent actif, avec blur et saturation controles. - Futur : preflight generant automatiquement la matrice modules modifies -> avancements roadmap. - Futur : capture QA automatique des overlays pour chaque couleur et Light/Dark. ## 4.5.311 - Surface & Mouvement v2 - [x] 12 styles de Surface distincts et visibles. - [x] 12 personnalités de Mouvement distinctes. - [x] Aperçu de surface et test de mouvement directement dans Design System & QA. - [x] Propagation du vocabulaire aux profils clients, Hub Client et Studio. - [x] Respect strict de `prefers-reduced-motion`. - [ ] Futur : presets métier Surface × Mouvement validés, capture automatique des états et score de confort visuel. ## 4.5.310 - Design Composer Web - [x] Compiler un profil Design Composer en tokens Web neutres pour Studio. - [x] Conserver une frontière stricte : Core = moteur design, Studio = composition/layout/effets, Hub Client = application page-scoped. - [ ] Ajouter score qualité, bibliothèque de composants gouvernés et QA responsive multi-breakpoints. - [ ] Ajouter une publication explicite vers Elementor Global Colors/Fonts avec preview, sauvegarde et rollback. ## 2026-10-21 - Core 4.5.308 - Compositeur dynamique Style x Couleur x Light/Dark x Densite. - Prochaines etapes : comparateur cote-a-cote, validation WCAG automatisee, QA combinatoire et historique de profils. ## Core AWM 4.5.307 / Suite 4.5.448 - table Dark et QA calculée - [x] Neutraliser le fond clair natif `widefat striped` au repos dans la table de référence Design System. - [x] Couvrir repos, alternance, hover, focus et sélection avec les tokens Core. - [ ] Ajouter un scanner de styles calculés pour repérer les règles WordPress/module qui gagnent encore sur Core. - [ ] Générer une matrice de captures preset × Light/Dark × état interactif. - [ ] Produire un rapport de spécificité CSS lors d'une régression. - [ ] Persister une session QA passe/à vérifier par route et preset. - [ ] Exporter le rapport QA avec URL, preset, thème et état contrôlé. ## Core AWM 4.5.306 - intégrité de version source - Aligner et valider automatiquement le header WordPress `Version:` et `AWM_CORE_VERSION` avant toute publication de Suite. - Conserver ensuite le triplet exact ZIP / manifest / roadmap comme garde de publication. ## 2026-10-20 - Core 4.5.302 / Suite 4.5.442 - Sélecteur explicite de style dans Design System & QA et dans Affichage. - Fermeture CSS terrain : priorité Core renforcée pour supprimer les arrondis legacy restants. - Futur prioritaire : diff visuel automatique, lint CSS, grille d espacement, responsive multi-breakpoints et audit WCAG. ## Maintenant - 4.5.298 / Suite 4.5.438 - [x] Auditer les pages, sous-pages, routes pont et onglets des neuf modules administratifs centraux. - [x] Corriger le melange Light/Dark observe dans Hub > Clients. - [x] Imposer un etat de theme canonique Core et synchroniser les alias legacy. - [x] Couvrir les ecrans natifs WordPress Campagnes/Appels de LeadTracker. - [x] Neutraliser les couleurs/gradients/ombres legacy des surfaces admin sans recolorer les apercus metier. - [x] Garder Hub Client completement exclu du Design System administratif. - [x] Memoire/Architecture/Revue Futur `2026-10-20.4`, 111 regles. - [ ] Validation terrain : parcourir Core, Hub, CRM, LeadTracker, Stats, Assistant, Soutien, Studio et Tech en Light puis Dark. - [ ] Prochaine nouveaute : matrice de captures visuelles automatisees Light/Dark par route. - [ ] Ajouter un lint CSS de livraison pour detecter gradients decoratifs, rayons > 4 px et couleurs legacy sur les primitives communes. - [ ] Ajouter des snapshots de contraste WCAG sur les composants admin critiques. - [ ] Centraliser le registre des routes AWM afin que toute nouvelle page herite automatiquement du Design System. ## Maintenant - 4.5.297 - [x] Centraliser le style administratif dans Core. - [x] Nouveau langage visuel bleu et carre, distinct des interfaces clientes. - [x] Charger la couche visuelle Core en dernier sur tous les modules AWM centraux. - [x] Exclure Hub Client de cette couche globale. - [x] Neutraliser dans l admin central les grands aplats/gradients de branding client tout en gardant logo et identite. - [x] Memoire/Architecture/Revue Futur 2026-10-20.3. - [ ] Valider visuellement Core, Hub, CRM, LeadTracker, Stats et Tech sur Alliance. - [ ] Migrer progressivement les anciennes declarations visuelles locales vers les tokens Core afin de reduire encore le CSS duplique. ## Maintenant - 4.5.296 - [x] Registre générique des CRM externes par client dans Core. - [x] Aucun secret fournisseur stocké dans la fiche client; clés conservées dans Core AWM. - [x] Capturia adopté comme premier fournisseur sans généraliser son affichage aux autres clients. - [x] Désactivation explicite persistante pour éviter qu une ancienne campagne réactive visuellement le CRM. - [ ] Terrain : confirmer Vendre Maison Vite = Capturia visible et Allo Déménagement = aucun CRM visible en Standard/Guidé. - [ ] Futur : contrat de santé fournisseur, rotation de credential, mapping par fournisseur et journal d intégration unifié. ## Maintenant - 4.5.295 - Conserver la livraison Capturia immediate validee terrain. - Garantir que les champs identite Capturia proviennent de valeurs humaines et jamais d un email/telephone/URL. - Valider le prochain vrai lead sans formulaire test artificiel. ## Livré localement — Core AWM 4.5.294 · Affichage par utilisateur - [x] Ajouter les modes Guidé / Standard / Avancé au shell commun AWM. - [x] Mémoriser le choix par utilisateur WordPress. - [x] Permettre le basculement instantané depuis l entête pour le développement et la formation. - [x] Garder Parcours guidés / Aides contextuelles / Options avancées dans Affichage. - [x] Garantir qu aucun mode ne change une donnée métier ou une permission. - [x] Fournir un composant de parcours guidé réutilisable par les modules. - [ ] Valider le basculement sur WordPress Alliance en Guidé / Standard / Avancé. - [ ] Confirmer l entrée V4.5.433 sur la roadmap publique après installation. --- ## 2026-10-15 - 4.5.293 / Suite AWM 4.5.415 - loi Capturia automatique + seed Mémoire versionné - Ajoute la règle critique `AWM-CAPTURIA-AUTO-ALL-FORMS-001` : quand Capturia VMV-NAT est actif, tout formulaire capturé du site principal est routé automatiquement, sauf mapping explicite vers une autre campagne. - Ajoute `AWM-SUITE-PACKAGING-SAFETY-001` après l incident 4.5.413 : aucun arbre de travail ne doit entrer dans un ZIP Suite publié. - Corrige le mécanisme de seed : `SEED_VERSION` passe à `2026-10-15.4` afin que les nouvelles lois ajoutées depuis 4.5.411 soient réellement importées dans une base Core déjà initialisée, sans réécrire les règles existantes. - Architecture et Revue Futur passent à `2026-10-15.4`. ## 2026-10-15 - 4.5.292 / Suite AWM 4.5.413 - loi multi-formulaires Capturia et diagnostic par lead - Ajoute la regle critique Memoire `AWM-CAPTURIA-FORM-SOURCES-001`: un moteur de formulaire explicitement cable et supporte ne doit jamais etre ignore par le routage Capturia VMV-NAT. - Memoire AWM embarquee: 104 regles. - Architecture AWM passe a `2026-10-15.3` et formalise le circuit Elementor / Gravity Forms / Contact Form 7 -> VMV-NAT -> Capturia -> preuve technique LeadTracker. - Le canal Core `client/forms/capturia-delivery` transporte maintenant source, identifiant du formulaire, phase et curseur de notes, toujours sans PII. - La regle d heure canonique existante est appliquee au diagnostic LeadTracker: stockage UTC, affichage America/Toronto HAE/HNE. - Revue Futur `2026-10-15.3`: prochaine nouveaute prioritaire proposee, matrice de sante des sources et alertes recu-sans-preuve. - Aucun lead, envoi Capturia, migration ou deploiement distant n est execute par Core a l installation. ## 2026-10-15 - 4.5.291 / Suite AWM 4.5.412 - Architecture du pipeline CRM et loi de provenance - Met à jour **Architecture AWM** vers `2026-10-15.2` : CRM AWM devient explicitement la source de vérité des opportunités et de leur état commercial. - Ajoute le flux transversal **Interaction CallTracker → opportunité CRM** : création explicite, référence source stable/idempotente, pipeline CRM, issue Gagné/Perdu. - Ajoute la règle Mémoire `AWM-CRM-OPPORTUNITY-SOURCE-001`; la Mémoire Core contient maintenant 103 règles embarquées. - Le déplacement d une opportunité ne peut jamais modifier le lead/appel/formulaire source, la campagne, le CPL ni sa qualification opérationnelle. - La revue Futur `2026-10-15.2` confirme le pipeline CRM 1.6.33 comme vraie nouveauté de cette Suite et conserve les prochaines nouveautés de chacun des dix modules. - Aucun lead, opportunité, campagne, facture, CPL ou statut n est créé/modifié par Core à l installation. - Les routes de sous-menu WordPress restent enregistrées conformément à la règle de stabilité 4.5.403. ## 2026-10-15 - 4.5.290 / Suite AWM 4.5.411 - Mémoire, architecture et revue Futur obligatoires - Ajoute **Core > Outils avancés > Architecture AWM**, un registre en lecture seule et exportable des responsabilités, sources de vérité, frontières de stockage, flux critiques et dépendances de la Suite. - Ajoute un snapshot **Revue Futur** couvrant les dix modules : maintenance/correctifs, améliorations et vraies nouveautés, recoupé avec la roadmap publique consultée en direct avant le build. - Ajoute les règles Mémoire `AWM-ARCHITECTURE-SOURCE-001`, `AWM-SUITE-FUTURE-REVIEW-001` et `AWM-CAPTURIA-CRM-PII-001`; le seed passe à `2026-10-15.1` sans réécrire les révisions existantes. - Les futures publications de Suite, une fois Core 4.5.290 actif, doivent déclarer `architecture_contract` et `future_review` dans leur manifeste, avec couverture des dix modules et URL de roadmap publique Alliance. - Architecture Capturia clarifiée : Capturia reçoit les données personnelles utiles du prospect VMV-NAT; seule la table de preuve AWM reste PII-free. - Aucun connecteur, campagne, CPL, prospect, déploiement distant ou migration métier n est lancé par cette version. Seul Core change. ## 2026-10-15 - 4.5.289 / Suite AWM 4.5.409 - Capturia : canal de preuve des nouveaux formulaires - Ajoute le canal Connector authentifié `client/forms/capturia-delivery` pour recevoir du site Vendre Maison Vite une preuve technique PII-free après l envoi d un formulaire VMV-NAT vers Capturia. - Core vérifie le client, le site appairé et l instance avant de transmettre le reçu à LeadTracker; aucune clé Capturia ni donnée nominative n est incluse dans ce reçu. - Le canal ne crée ni contact, ni campagne et ne modifie aucun CPL. Les outils et la clé API Capturia restent centralisés dans Core. - Mémoire de développement : règle `AWM-CAPTURIA-PROOF-ARCHIVE-001` ajoutée; les règles existantes sont conservées. ## 2026-10-15 - 4.5.288 / Suite AWM 4.5.405 - Capturia dans Core - Ajoute **Capturia - Vendre Maison Vite** dans `Core AWM > Connexions > Coffre et cles`. - La nouvelle cle API peut etre remplacee directement dans Core, sans trousseau v2 obligatoire pour cette operation; elle reste chiffree au repos par le coffre Core existant. - Bouton de test en lecture uniquement (`/me`, un contact, une source); aucune ecriture fournisseur durant le test. Les scopes d ecriture sont seulement detectes et affiches. - La cle n est jamais reaffichee ni journalisee. Capturia reste strictement limite a Vendre Maison Vite. - La connexion peut ensuite etre promue dans le trousseau v2 lorsque celui-ci est prepare. - LeadTracker 1.11.56 lit cette cle Core en priorite et conserve l ancienne cle par campagne uniquement comme repli de compatibilite. - Aucun lead, CPL, source Capturia, campagne ou statut commercial n est modifie lors de l installation. ## 2026-10-14 - 4.5.287 / Suite AWM 4.5.404 - CRM Clients Canal CRM client prive dans Core, sans stockage metier parallele; garde client/site/instance/autorisation et chiffrement Core existant. Candidate de migration additive : tests locaux, essai WordPress/MySQL et sites clients requis. Aucun transfert a l'installation. Ne supprime ni sources historiques, ni audio Twilio. Un seul lancement global depuis CRM AWM > CRM Clients - campagnes et leads. Prealables : trousseau Core enrole et sauvegarde separement; Hub Client 1.14.22 sur sources et destination; autorisations techniques. Le statut commercial et le statut des campagnes ne sont pas modifies. Capturia n'est jamais exige ni active pour les autres clients. --- ## 2026-10-14 - Core 4.5.286 / Suite 4.5.403 - Acces aux mises a jour retabli - Regression 4.5.285 reproduite : compact_menu retirait les routes secondaires de `$submenu`. Le parent WordPress devenait vide et le hook recherche ne correspondait plus au callback enregistre, causant un faux refus d'acces. - Toutes les routes enregistrees restent dans le registre WordPress. Le menu conserve cinq rubriques visibles; seules les lignes secondaires du menu lateral sont masquees par une classe CSS. - Les permissions, callbacks, nonces, moteurs de mise a jour, import par paquets et Recovery ne sont pas modifies. Les extensions tierces du menu restent visibles. - Secours distinct `awm-core-menu-rescue` 1.0.0 : restaure temporairement le menu complet uniquement sur Core 4.5.285, sans installer Core, sans ecriture metier et sans neutraliser les protections d'installation. Inerte sur 4.5.286. - Memoire : nouvelle regle AWM-CORE-NAV-ROUTES-001; 95 regles precedentes preservees; seed 2026-10-14.3; schema DB inchange. - Tests locaux de routage/permissions et rendu de l'import. Pas de validation sur WordPress Alliance, ni de deploiement ou de restauration SQL reels. Roadmap publique non verifiee. --- ## 14 octobre 2026 - Core AWM simplifié (4.5.402 / 4.5.285) ### Codé et validé localement, essai pilote requis Cinq espaces, accueil par tâches, liens historiques conservés, recherche d'outils selon les droits, CSS Core clair/sombre et correctif Mémoire AWM. Diagnostics en second niveau; pas de changement des moteurs de coffre ou de déploiement. ### Prochain contrôle terrain Importer sur un pilote, comparer versions effectives, ouvrir les anciennes URL, tester les profils autorisés et refusés, relire les formulaires de coffre/import/utilisateurs/Recovery. Vérifier le contraste avec les personnalisations réelles et l'absence de régression sur Hub, CRM, LeadTracker et Tech. Publier puis vérifier la roadmap publique : non confirmé ici. ### Architecture suivante, non livrée par ce correctif UX Centraliser dans Core les connecteurs et outils API restants; CRM Client doit devenir le stockage métier chiffré et le registre unique des prospects à vie par entreprise. LeadTracker consultera sans copie persistante; Stats et CPL consommeront les indicateurs nécessaires. Audio conservé chez Twilio, références seulement dans CRM Client. Le statut commercial restera indépendant des campagnes et de la collecte. La nouvelle navigation prépare ces travaux sans les simuler. --- ## Historique conservé ## Suite 4.5.401 / Core 4.5.284 - état exact du chantier Les cases cochées indiquent du code livré et testé localement, pas une validation production. - [x] Service Core de chiffrement v2 avec trousseau externe, rotation conservant les anciennes clés et index stable par client. - [x] Écran Coffre et connexions avec contrôles d'accès, confirmations, migration/relecture et diagnostic sans secret affiché. - [x] Trois configurations globales Twilio/Google Ads centralisables sans changer leurs consommateurs existants. - [x] Tests cryptographiques, erreurs/écritures/concurrence simulées, fichier privé, CLI, formulaire et responsive local. - [x] Mémoire, README, CHANGELOG, notes, guide technique, validation et manifeste synchronisés. - [ ] Valider sauvegarde/restauration, WordPress SQL réel et connexions fournisseurs sur un pilote avant généralisation. - [ ] Migrer Capturia, Screpy, IA, WooCommerce et autres accès; consolider leur configuration uniquement dans Core. - [ ] Migrer les secrets de connecteurs/déploiement avec protocole de rotation authentifié sans rupture des sites. - [ ] Enforcer les autorisations fines client/site/utilisateur/opération à chaque API métier; pas de confiance dans un simple nom de module transmis. - [ ] CRM Client unique stockage des leads chiffrés et des références Twilio. LeadTracker lecteur autorisé sans copie persistante; Stats/CPL seulement indicateurs non nominatifs. - [ ] Registre d'acquisition unique à vie par client CRM, import historique idempotent/ambiguïtés, attribution et calcul CPL corrigé après validation. - [ ] Activation CRM Client pour tout client possédant une campagne, découplée du statut commercial. Ne pas retirer les autres garde-fous de suppression, archivage, droits ou identité. - [ ] Publication visible de la roadmap en ligne et validation terrain de cette version. Les fichiers audio restent chez Twilio. Aucun rapatriement ni suppression d'enregistrement fournisseur n'est prévu dans cette architecture. --- ## Phase pilote — 4.5.283 / partage sécurisé de la connexion Capturia existante Nouvelle route Connector de délivrance limitée au bon client/site/campagne SEO, données protégées HTTPS, fail-closed; conserver l'audit et vérifier sur un WordPress réel avant publication publique. # Core AWM 4.5.282 — socle LeadTracker / CRM Client - [x] Branding visible LeadTracker avec compatibilité technique CallTracker. - [x] Route Connector site-scoped pour l état des modules. - [x] Onglet Câblage des leads. - [ ] Contrat de permissions par famille de connecteur et type de donnée. - [ ] Consentement révocable et traçable pour les exports identifiables. ## 4.5.281 — fiabilité de l’état Mises à jour - [x] Ne plus afficher 100 % lorsqu’un module de même version a une empreinte locale inconnue. - [x] Afficher **Build à vérifier** / **Build différent** au lieu de **À jour** dans ces cas. - [x] Autoriser une réinstallation sûre d’un même numéro de version depuis le paquet signé lorsque le build local n’est pas vérifié. - [x] Conserver Core en dernier, les sauvegardes locales, SHA-256, validation de version et réactivation. - [x] Republier CallTracker sous 1.11.37 afin de forcer le correctif Capturia même si 1.11.36 est déjà installé. - [ ] Validation terrain : confirmer que la Suite 4.5.366 affiche Core 4.5.281 + CallTracker 1.11.37 comme mises à jour, puis que la barre atteint 100 % seulement après installation réussie. ## 4.5.280 — import Suite déterministe - [x] Résoudre le paquet de chaque module depuis le nom exact déclaré dans le manifeste avant tout repli par préfixe. - [x] Conserver la validation stricte des versions et SHA-256. - [x] Éviter qu’un ancien ZIP résiduel d’une Suite ne bloque la publication du bon paquet. ## 4.5.279 — synchronisation CPL provenance - [x] Publier CallTracker 1.11.32 et Hub 4.5.67 dans la roadmap publique. - [x] Documenter la priorité Manuel > Auto et le backfill contrôlé des lignes 7 %. ## 4.5.278 — synchronisation CPL complet - [x] Publier CallTracker AWM 1.11.31 et Hub AWM 4.5.66 dans la roadmap publique. - [x] Publier le statut mensuel CPL Complet / À compléter avec source, devise et fraîcheur. - [x] Documenter les paramètres mensuels rabais / réceptionniste / autres coûts et leur application automatique. - [x] Préserver la provenance Google Ads lors d une modification des frais annexes. - [x] Publier la synchronisation Google Ads de toutes les campagnes mappées avec progression. - [x] Conserver les 214 appels historiques manquants comme écart connu non bloquant. - [ ] Validation terrain : confirmer un mois Google Ads réel, puis modifier uniquement les frais annexes et vérifier que la source reste Google Ads. - [ ] Validation terrain : lancer « Synchroniser toutes les campagnes » et confirmer que le cycle atteint toutes les campagnes mappées. - [ ] Confirmer `/hub/roadmap/` après installation de la Suite correspondante. ## 4.5.277 — synchronisation CallTracker 1.11.30 - [x] Publier le correctif UX des actions groupées CallTracker 1.11.30. - [x] Retirer de la roadmap opérationnelle le parcours natif WordPress `Modification groupée` au profit du seul panneau CallTracker. - [x] Documenter le panneau pleine largeur dans la barre Recherche / filtres. - [x] Conserver les garde-fous serveur 1.11.29 sans modification. - [ ] Confirmer `/hub/roadmap/` après installation de la Suite correspondante. ## 4.5.276 — synchronisation CallTracker 1.11.29 - [x] Publier CallTracker 1.11.29 et les actions groupées métier guidées. - [x] Exposer Activer/Pause/Réattribuer comme actions courantes avec aperçu serveur. - [x] Documenter Archive/Corbeille/Libérer Twilio/Supprimer comme zone sensible avec confirmations et garde-fous. - [x] Marquer 1.11.28 tri métier + vues technicien comme validé terrain. - [x] Conserver l écart historique de 214 appels comme non bloquant. - [ ] Confirmer `/hub/roadmap/` après installation de la Suite correspondante. ## 4.5.275 — synchronisation CallTracker 1.11.28 - [x] Publier dans `/hub/roadmap/` le tri métier serveur de CallTracker. - [x] Publier les vues technicien Toutes / À vérifier / Sans client / Sans numéro. - [x] Conserver l écart de 214 appels historiques comme non bloquant. - [ ] Confirmer la page publique après installation de la Suite 4.5.354. ## Core AWM 4.5.274 — historique total CallTracker publié - [x] Publier CallTracker AWM 1.11.27 dans la roadmap publique. - [x] Marquer **Historique total dans Campagnes** comme Livré. - [x] Documenter la séparation entre activité 30 jours et historique cumulé appels + formulaires. - [x] Reclasser les 214 appels historiques restants comme écart connu non bloquant. - [ ] Validation terrain : confirmer après installation que `/hub/roadmap/` affiche CallTracker 1.11.27 et que VMV-NAT/Soltech montrent les totaux historiques. ## Core AWM 4.5.273 — roadmap publique terrain - [x] Publier la validation terrain du correctif formulaires historiques CallTracker 1.11.26. - [x] Marquer le cas témoin VMV-NAT comme conforme : vrai courriel, téléphone et page source. - [x] Afficher publiquement l état réel de la réintégration : 44 712 / 44 712 formulaires et 69 092 / 69 306 appels présents. - [x] Conserver les 214 appels historiques manquants dans **Maintenant**, sans les masquer comme terminés. - [ ] Validation terrain restante : réparer uniquement les 214 appels refusés et confirmer 69 306 / 69 306. ## Core AWM 4.5.272 — livré / validation terrain - [x] Identifier `callink-dashboard` comme contexte CallTracker dans le shell partagé. - [x] Afficher le header CallTracker AWM et rendre l onglet Tableau de bord actif. - [x] Synchroniser la roadmap publique avec le dashboard clients/campagnes, le détail complet des formulaires et la récupération audio Twilio. - [ ] Validation terrain : confirmer le header, un formulaire Elementor complet et la lecture d un appel dont le Recording SID local était absent. ## Core AWM 4.5.271 — livré / validation terrain - [x] Stocker l inventaire formulaires provenant de `update/status`. - [x] Alimenter CallTracker par site Connector exact. - [x] Respecter la déduplication/verrou d inventaire par site. - [ ] Valider la détection immédiate Soltech racine + `/region`. ## Core AWM 4.5.270 — inventaire formulaires par site - Transporte et persiste de façon site-scoped l inventaire Gravity Forms/Elementor fourni par Hub Client pour l UX CallTracker. ## Livré 4.5.266 - Repli de transport automatique sur paquet vide (`awm_update_download_empty`). - Conserver Recovery au roadmap futur comme certification asynchrone non bloquante. ## Livré 4.5.265 - Recovery temporairement retiré du chemin bloquant de l Autopilote pour stabiliser la flotte. - Statut opérationnel simplifié : Hub/Tech/modules conformes = `À jour`. - Les mécanismes Recovery restent dans le code et la Suite. ## Futur — réintégration Recovery - Réactiver Recovery uniquement après validation terrain de la flotte. - Le remettre comme certification asynchrone indépendante qui ne bloque jamais le worker principal. - Réutiliser les preuves fichiers + SQL, sandbox et rollback sans ralentir le déploiement Hub/Tech. - Ajouter un tableau séparé de santé Recovery et des alertes ciblées au lieu de bloquer toutes les mises à jour. ## Livré 4.5.264 - [x] Statut final explicite `À jour · Recovery certifié`. - [x] Certification Recovery des WordPress utilisant une base partagee avec isolation par prefixe. ## 4.5.263 — Tech systeme par defaut + inventaire anti-regression - [x] Tech actif par defaut; seule une desactivation manuelle CRM explicite le coupe. - [x] Installer/activer Tech automatiquement des le pairing Hub Client. - [x] Mettre Tech a niveau avant Recovery lorsqu une version plus recente est publiee. - [x] Ne plus laisser Recovery bloquer l installation ou la mise a niveau de Tech. - [x] Empêcher une ancienne telemetrie d ecraser une version Hub Client/Tech plus recente deja confirmee. - [x] Conserver le parcours Hub -> Tech -> Recovery -> autres mises a jour, avec rollback et fail-closed Recovery. - [ ] Validation terrain : Climat NordSud et Plomberie Soltech ne doivent plus rester `Tech a installer`; Demenagement Hull ne doit plus regresser visuellement vers une ancienne version. ## 4.5.260 — Même flotte écran / worker - [x] Unifier le critère de connexion de `connected_clients()` et du worker Autopilote. - [x] Inclure les Connectors `state=connected` même si `runtime_authorized` n est pas encore persisté. - [x] Empêcher la fin prématurée de la vague après les seuls sites `runtime_authorized=1`. - [x] Conserver l exclusion des clients non opérationnels et des Connectors réellement déconnectés. - [x] Conserver Recovery fail-closed et toutes les protections de déploiement. ## 4.5.259 — Autopilote jusqu au dernier site - [x] Éviter la déduplication WordPress des événements cron de continuation avec un jeton unique par lot. - [x] Planifier le lot suivant comme immédiatement dû avant `spawn_cron()`. - [x] Conserver `worker_status=queued` entre les lots et réserver `idle` à la fin réelle du cycle. - [x] Continuer même si un site est bloqué Recovery ou en erreur. - [ ] Validation terrain : exécuter une vague complète sur les 15 sites connectés et confirmer le passage jusqu au dernier site sans nouveau clic. ## 4.5.258 — File Autopilote persistante - [x] Continuer automatiquement au lot suivant après libération du verrou worker. - [x] Ne plus limiter le bouton manuel à un seul site. - [x] Ne plus recharger toute la page après le premier lot. - [x] Rafraîchir silencieusement les lignes pendant la poursuite en arrière-plan. - [x] Conserver Recovery fail-closed et isoler les erreurs par site. ## 4.5.257 — Recovery zero-clic - [x] Faire de Hub Client un prerequis auto-reparable du parcours Recovery. - [x] Eliminer le cercle Hub ancien -> Recovery impossible -> Hub impossible a mettre a jour. - [x] Lancer automatiquement validation objective du scope + checkpoint + test fichiers/SQL depuis l Autopilote. - [x] Reprendre Tech et les mises a jour sans clic lorsque Recovery devient pret. - [x] Simplifier l UX : **Reparer la selection** remplace la preparation Recovery manuelle dans le parcours normal. - [ ] Validation terrain sur Plomberie Soltech principal + /region avec preuve de reprise complete. # Roadmap publique Suite 4.5.319 — 4.5.255 **Livré :** Synchronise /hub/roadmap avec l UX Campagnes Appels/Formulaires, le pilotage Elementor/Gravity Forms depuis Alliance et la suppression logique sécurisée des fiches clients CRM. **Validation terrain :** confirmer le parcours sur un site pilote avant généralisation à toute la flotte. # Core AWM 4.5.254 - Autopilote Recovery auto-réparable ## Livré - [x] Réparer/inspecter automatiquement Recovery lorsqu une mise à jour de flotte est détectée. - [x] Relancer automatiquement le vrai test fichiers + SQL lorsque le périmètre a déjà été confirmé. - [x] Reprendre le déploiement automatiquement dans le même passage dès que `recovery_ready_for_auto=1`. - [x] Garder une confirmation humaine unique lorsque l absence d écrivains externes n a jamais été confirmée. - [x] Ajouter **Préparer Recovery** pour les sites sélectionnés avec progression et poursuite malgré un site bloqué. - [x] Relancer automatiquement l Autopilote après une préparation Recovery réussie. - [x] Journaliser réparation, test, attente de confirmation et blocages sans masquer les erreurs Recovery. ## Validation terrain - [ ] Sélectionner 2 à 3 sites avec `Recovery requis`, lancer **Préparer Recovery** une seule fois et confirmer que chaque site est traité indépendamment. - [ ] Confirmer qu un site déjà approuvé mais sans test valide exécute automatiquement le test fichiers + SQL et passe ensuite sa mise à jour sans clic manuel. - [ ] Confirmer qu un site non approuvé reste bloqué avec demande de confirmation, sans forçage. - [ ] Vérifier le journal de sécurité et le ROADMAP public après publication Suite 4.5.318. ## Historique 4.5.253 - Transport Suite/module par paquets XHR 512 Ko, sans iframe. - Paquet de secours ponctuel **AWM Core Packet Bootstrap** conservé pour sortir d un verrou circulaire où un ancien Core bloque sa propre mise à niveau. - Bootstrap limité au remplacement de Core, avec manifeste SHA-256 du payload, validation de version, stage local, bascule par renommage et rollback si la bascule échoue. # Core AWM 4.5.252 - import par paquets XHR sans iframe - [x] Decouper les ZIP Suite/module en paquets de 512 Ko. - [x] Envoyer les paquets uniquement par XMLHttpRequest. - [x] Utiliser `admin-ajax.php` relatif a l origine exacte du wp-admin comme endpoint principal. - [x] Garder un repli XHR same-page, sans iframe et sans lecture cross-origin. - [x] Assembler cote serveur et verifier taille + SHA-256 avant import. - [x] Conserver la limite globale de 256 Mo avec 512 paquets maximum. - [x] Conserver nonce, validation documentaire, manifeste, depot prive et no-downgrade. - [ ] Valider sur Alliance avec Suite 4.5.314 puis conserver ce test dans les publications suivantes. # Core AWM 4.5.249 - transactions v3 orphelines - [x] Detecter une transaction v3 ouverte vers une cible plus ancienne lors d un deploiement manuel. - [x] Tenter de la finaliser puis de la commit avant toute nouvelle ecriture. - [x] Rollback lie au `deployment_id` uniquement si la finalisation precedente n est plus possible. - [x] Abandonner `verified`/`staged` anciens sans toucher la production apres 5 minutes. - [x] Conserver no-downgrade, Recovery fail-closed, HMAC/SHA-256 et verification sur requete fraiche. - [ ] Valider sur le site Vendre Maison Vite - VMV-GADS bloque par `awm_deploy_resume_target_conflict` avant de generaliser a l Autopilote. # Core AWM 4.5.248 - Simplification Hub Client - [x] Revenir a un Hub Client WordPress classique comme etat normal unique. - [x] Ne plus exiger AWM System Agent dans la preuve de sante Hub 1.14.2+. - [x] Harmoniser la flotte par lots de 4 et continuer si un site echoue. - [x] Utiliser Tech/System Agent uniquement comme secours de transition si Hub est indisponible. - [x] Nettoyer les anciens artefacts AWM MU seulement apres preuve `classic_mode + boot_ok`. - [x] Conserver SHA-256, HMAC, sauvegarde/rollback v3, no-downgrade, site_id et permissions. - [ ] Apres harmonisation terrain, retirer le code de compatibilite MU devenu inutile. # Core AWM 4.5.247 - Réharmonisation flotte - [x] Réparer les sites déjà équipés de System Agent. - [x] Mettre à niveau les anciens Hub encore joignables vers 1.14.1. - [x] Laisser Hub 1.14.1 auto-semer System Agent 2.0.1. - [x] Utiliser Tech Rescue uniquement pour réactiver un Hub existant avant mise à niveau. - [x] Continuer la vague même si certains sites restent bloqués. - [x] Exiger Hub 1.14.1 + safe_legacy + boot_ok + System Agent comme preuve finale. - [ ] Étendre cette mécanique aux autres modules après stabilisation terrain. # Core AWM 4.5.246 - Patch flotte Hub sécurisé - [x] Patch Hub flotte System-Agent-only depuis le central. - [x] Lots de 2 sites et progression visible. - [x] Confirmation obligatoire `safe_legacy` + `boot_ok` par site. - [x] Aucun repli ancien Rescue/Tech pendant la vague. - [x] Arrêt automatique après 3 échecs consécutifs. - [x] Sites bloqués laissés intacts et journalisés. - [ ] Retirer le mode safe_legacy seulement après stabilisation terrain multi-sites. - [ ] Étendre System Agent aux déploiements Tech/Studio après validation terrain. # Core AWM 4.5.245 - System Agent fail-safe - [x] Canal de secours MU indépendant de Hub Client. - [x] Installation Hub Client signée et SHA-256 via System Agent. - [x] Activation dans une requête séparée et vérification `safe_legacy`/`boot_ok`. - [x] Arrêt fail-closed si l agent système répond mais ne peut pas réparer. - [x] Plus aucun cutover MU automatique pour Hub Client 1.14.0+. - [x] Conserver Recovery/autopilote fail-closed. - [ ] Étendre System Agent aux déploiements Tech/Studio après validation terrain Hub. # Core AWM 4.5.244 — stabilité flotte avant remise en MU - [x] Exiger une preuve `rescue_legacy` avant de remplacer un Hub Client non-MU-complet. - [x] Bloquer AVANT écriture si le garde MU ne peut pas être confirmé. - [x] Supprimer le double pré-armement dans le parcours Réparer. - [x] Conserver Recovery fail-closed et les preuves de transaction v3. - [ ] Après restauration complète de la flotte, ajouter une action séparée « Remettre en MU » avec autorisation courte et preuve de requête fraîche. # Core AWM 4.5.243 — restauration de flotte avant remise en MU - [x] Pré-armer un garde MU avant la mise à jour Hub Client lorsque la migration courante est incomplète. - [x] Accepter une preuve `rescue_legacy` uniquement sur intervention administrateur manuelle. - [x] Fermer proprement la transaction Hub Client sans prétendre que MU est complet. - [x] Permettre ensuite la poursuite des mises à jour Tech AWM. - [x] Garder l Autopilote fail-closed pendant le mode de secours. - [ ] Valider Allo Déménagement principal puis ALLO-DEM-GADS. - [ ] Après stabilisation, ajouter une action contrôlée de remise en MU site par site avec preuve sur nouvelle requête. - [x] Supporter le test Recovery SQL sur hebergement mutualise sans privilege CREATE DATABASE via sandbox de tables isolees. ## Livré 4.5.267 - Repli multi-transport signé pour les derniers sites dont le WAF/proxy refuse certains endpoints WordPress. ## Livré 4.5.268 - [x] Transport statique éphémère de paquet pour les réparations/déploiements manuels afin de contourner les réponses ZIP vides et HTTP 503. - [x] Validation locale taille + SHA-256 avant exposition temporaire du ZIP. - [x] Conservation des transports admin-post, REST, admin-ajax et frontal comme replis. - [ ] Futur : réintroduire Recovery comme certification asynchrone indépendante qui ne bloque jamais l’Autopilote principal. ## Livre 4.5.269 - [x] Cadence Autopilote a 1 site par lot. - [x] Delai inter-site pour eviter les rafales. - [x] Verrou d inventaire par site et deduplication multi-onglet/worker. - [x] Polling navigateur sequentiel sans chevauchement. - [x] Decode JSON resilient aux parasites serveur. ## 2026-10-21 — Design Composer v2 - Livré : familles typographiques, surfaces indépendantes, mouvement contrôlé. - Futur : iconographie par famille, personnalité KPI/tableaux, score qualité du thème, QA combinatoire automatisée. ## 2026-10-21 — Core 4.5.318 - [Livré] Pont autoritaire Design Composer pour la route Hub AWM > Clients, avec fallback serveur + JS et protection des cartes client. ### 4.5.319 — Autorité Light/Dark inter-routes - Synchronisation unique du mode thème Core sur Hub Clients legacy. - Garde CSS contre une branche Light gagnante en présence d un marqueur Dark.