CHANGELOG

## 1.10.18 — 2026-10-12 — Elementor depuis WordPress administrateur sans mot de passe

- Correction du démarrage Elementor via la session WordPress complète : chargement des capacités à `wp_loaded`, avant les menus, y compris sur `post.php?action=elementor`; aucune extension des droits des anciennes sessions limitées à une page.
- Supprime la mauvaise exigence de correspondance avec l'URL d'une seule page pour un administrateur WordPress temporaire : `edit_post` de WordPress décide pour chaque document.
- Corrige le conflit d'origines `couture-electro.com` / `www.couture-electro.com` : code de passage unique (90 secondes maximum) lié au compte temporaire, à la session, à la page et à l'hôte canonique; WordPress recrée ses propres cookies sur cet hôte, sans cookie d'authentification admin partagé.
- Quand la session temporaire fonctionne sur l'hôte canonique, les URLs admin et AJAX produites dans WordPress restent sur le même hôte. Seuls les couples HTTPS apex / www strictement identiques sont acceptés; les autres origines ne sont pas redirigées.
- Dans l'éditeur Elementor administrateur, la fenêtre Tech n'est créée qu'après un aperçu effectivement chargé. Les anciennes sessions Elementor limitées conservent leur comportement.
- Audit de passage et de préparation de l'éditeur (identifiants techniques seulement); aucun jeton, mot de passe ou contenu de page enregistré. Pas de modification d'Elementor ni des contenus clients.
- 25 assertions simulées incluant droits précoces, contrôle des origines, code unique, refus de rejeu, expiration et distinction session limitée/administrateur. Test de bout en bout sur vrai WordPress et diagnostic d'extensions tierces encore nécessaires.

## 1.10.17 — 2026-10-12 — Journal des interventions durable et interface wp-admin

- La fenêtre flottante Tech n'est plus affichée sur les pages classiques `/wp-admin/` : l'accès administrateur temporaire sans mot de passe reste identique. L'éditeur Elementor et le frontend conservent leur interface d'intervention.
- Toute modification WordPress reconnue par les hooks Tech AWM est écrite immédiatement dans une nouvelle table locale dédiée `{$prefix}awm_tech_audit_spool` avec `event_id`, `session_id`, nature, objet et horodatage UTC; aucun mot de passe, token, cookie ni contenu client n'est persisté.
- Remplace l'ancienne file `wp_options` limitée à 500 événements par une file SQL sans éviction silencieuse. Migration des événements historiques non envoyés, sans suppression avant confirmation. Copie de secours si la base locale n'est pas accessible.
- Envoi par petits lots (25) vers Core AWM avec accusé de réception, déduplication sur identifiant d'événement et séparation stricte des sessions. Un événement ancien non transmis n'est jamais attribué au nouveau technicien.
- Tech AWM central > Journal : chronologie des ouvertures, refus et modifications WordPress reçues; recherche par client, site, technicien, action ou objet, avec pages de 40. Une simple requête est identifiée comme observation, jamais comme modification confirmée.
- Les événements livrés restent dans la file locale 365 jours; les événements en attente ne sont pas purgés automatiquement. Les logs Core respectent leur politique de rétention propre.
- Limites : les actions WordPress qui ne déclenchent aucun hook peuvent ne pas être recensées; la désactivation du plugin ou l'intervention directe sur fichiers/SQL empêche un audit exhaustif. Les données d'une ancienne session expirée restent localement en attente si leur envoi a échoué; leur réconciliation sécurisée reste à développer.
- Validation locale PHP des files, de la migration et du journal de consultation. La validation sur un WordPress client et l'affichage public de la roadmap restent à confirmer.

## 1.10.16 — 2026-10-12 — SSO wp-admin : restauration des capacités avant les menus

- Cause de la page « Sorry, you are not allowed to access this page » : les capacités temporaires du compte Tech étaient restaurées à `admin_init`, **après** le chargement de `wp-admin/menu.php`. WordPress pouvait déjà avoir mémorisé les menus comme interdits pour le rôle de base lecture seule.
- Le contrôle central de session se déclenche maintenant à `wp_loaded` (priorité 0, après le boot du module à `init` et **avant** les menus), avec un repli `admin_init` sans double validation. Aucun droit `administrator` n'est stocké durablement.
- En cas d'absence d'autorisation, le compte reste en lecture seule et la connexion est refusée; la révocation ferme la session et son cookie. Des diagnostics expurgés (`admin_page_denied`, `admin_session_capabilities`) sont consignés localement.
- Séparation des identités WordPress temporaires `frontend/elementor` et `wp_admin`; les nouveaux comptes admin conservent un rôle permanent minimal. Une ancienne identité reprise est ramenée au rôle lecture seule lors du passage admin.
- Vérification des capacités `manage_options` et `activate_plugins` avant la redirection; message explicite à la place d'une fausse réussite silencieuse.
- Tests simulés : 18 assertions de contrôle précoce, expiration, révocation, séparation des privilèges et audit; syntaxe PHP, JS, JSON et ZIP à contrôler lors de l'emballage.
- À confirmer sur un **vrai WordPress** : bouton Monitoring → WordPress, administration des extensions, journal d'audit, navigation entre plusieurs pages et éventuelles extensions de sécurité.
- L'édition Unicode de la 4.5.391, SSL/DNS, Recovery, Autopilote, CRM, CallTracker/CPL et les autres modules ne sont pas modifiés. La restauration de la page couture-electro.com demande toujours une révision saine vérifiée.

## 1.10.15 — 2026-10-12 — Sélection strictement ciblée + verrou Hub Client Unicode
- `replace_text` requiert un `element_id` explicite ; plus aucune substitution globale dans toute la page. Recherche uniquement dans les vrais champs de contenu éditables, un seul champ cible.
- La sélection d'une section fournit au modèle ses widgets enfants ; au moment d'appliquer, le serveur recalcule les IDs réellement descendants du conteneur sélectionné et refuse toute action externe.
- Limite de trois widgets concernés par une même action ciblée ; rejette les modifications non ciblées du titre, l'ajout global de section ou les CSS globaux.
- Le navigateur transmet la sélection au serveur et affiche le nouveau texte proposé (aperçu borné) avant approbation.
- Refuse toute écriture de page si Hub Client est plus vieux que 1.14.20, sans bloquer l'accès normal aux diagnostics et à WordPress.
- Les permissions temporaires, l'audit, SSL/DNS, Autopilote, Recovery et le CPL ne changent pas.
- Restauration historique : les snapshots créés avant ce correctif peuvent être eux-mêmes altérés par l'ancien double unslash ; préférer une révision Elementor saine.

## 1.10.14 (2026-10-12) — permission admin héritée de Tech + ouverture non bloquante

- WordPress : administration complète est activée par défaut pour les clients CRM actifs avec Tech AWM actif. L'autorisation n'est effective que pour un site Connector autorisé et une intervention centrale valide. Les anciens booléens `false` provenant de l'ancienne case décochée ne sont pas interprétés comme refus manuel; un nouvel indicateur explicite de refus conserve toute désactivation demandée à partir de cette version.
- Dans les permissions Tech du client, désactiver volontairement la case enregistre le refus; la réactiver efface ce refus. Désactiver Tech ou le client CRM coupe immédiatement l'accès; le refus persiste après une réactivation de Tech.
- Monitoring : les formulaires ouvrant un nouvel onglet sont désormais soumis SYNCHRONEMENT pendant le clic, sans animation bloquante sur la page centrale (corrige le blocage des fenêtres contextuelles dû au `setTimeout`).
- Intervention sur la même page : chargement arrêté après 20 secondes, état cliquable restauré et erreur utile. Les vérifications de permission et de version agent s'exécutent avant les préparations longues; l'accès WordPress ne déclenche plus un déploiement d'agent inattendu.
- Journal local, Core Security Log, connexion à usage unique, privilèges dynamiques, politiques CRM/Connector/site_id et contrôles HTTPS préservés. À tester sur un véritable site WordPress; aucune garantie d'audit des extensions tierces contournant les hooks.

## 1.10.13 (2026-10-11) — administration temporaire complète et audit

- Rétablit les deux raccourcis WordPress et Tech sur site dans Monitoring (cartes responsive).
- SSO WordPress sans mot de passe client via code de passage à usage unique, session liée au client/site/instance et HTTPS.
- Droits d’administration WordPress accordés uniquement pendant la session temporaire AWM validée; rôle de base lecture seule, aucun rôle administrateur persistant.
- Autorisation distincte explicite `wordpress_full_admin`, initialement désactivée (permissions CRM Tech).
- Journal local et central des changements contenus/Elementor/plugins/thèmes/utilisateurs/options et repli de traçage des requêtes tierces.
- File locale d’événements non synchronisés avec protection anti-attribution à un autre technicien; pas de PII ou secrets enregistrés.
- Contrôles HTTP/DNS, Autopilote, Recovery, CPL, protection de formulaires et autres modules préservés.

# Tech AWM 1.10.12 — 2026-10-11 — Monitoring unifié et alertes DNS avec preuve

- **Monitoring :** fusion des deux tableaux « Monitoring des sites » et « Certificats, DNS et santé WordPress » en une seule carte responsive par site géré (client CRM actif + Connector autorisé). Indicateurs de santé, SSL, DNS, WP-Cron, SQL, alertes, mises à jour et accès Fiche Tech réunis.
- **Recherche locale :** filtres par nom, domaine, zone DNS, serveurs NS et adresses A/AAAA/CNAME; états, pagination 12/24/48 sans défilement horizontal ni requête supplémentaire.
- **DNS lisibles :** découverte de la zone DNS via SOA (utile pour `www`), affichage NS réellement retournés (p. ex. `ns1.alliancewebmarketing.ca`) et destination A/AAAA/CNAME. Aucune identification de fournisseur inventée.
- **Avertissements DNS :** conservation des valeurs antérieures et nouvelles, confirmation par deux relevés concordants séparés d’au moins 30 minutes, file prioritaire pour recontrôler les changements en attente, journal d’audit et courriel aux seuls techniciens Tech configurés. Déduplication par zone et transition, sans alerte au premier relevé, sans email aux clients.
- **Compatibilité :** ancien schéma DNS 1.10.11 rebasé silencieusement lors de la première mesure version 2; aucune fausse alerte liée à l'ajout des NS de zone. Alertes configurables dans Tech → Réglages → Notifications et escalade, activées par défaut pour les destinataires techniques.
- **Sécurité :** lecture seule, validation des noms hôtes et adresses publiques pour SSL, permission/nonce existants, clients CRM actifs et Connectors autorisés. Historique conservé pour audit; pas de modification DNS, pas de données SQL client envoyées par courriel.
- **Tests locaux :** harnais PHP sur vraies classes Tech (NS/zone, changements, migration, courriels, doublons, client inactif, rendu), lint PHP/JS et intégrité ZIP. Vérification visuelle sur le WordPress réel et livraison effective des courriels SMTP encore à confirmer.
- **Inchangé :** modules Core, Hub, Hub Client, CRM, CallTracker/CPL, Stats, Studio, Soutien, Assistant et Recovery; sondes HTTP, Autopilote et interventions client inchangés.

# Tech AWM 1.10.11 — Diagnostics SSL, DNS, WP-Cron et SQL — 2026-10-11

- **Fonctionnel, phase 1 :** certificat HTTPS et dates d expiration, empreinte de changement DNS, retard WP-Cron et poids des options WordPress autoload / statistiques des tables SQL.
- **Source de vérité :** seuls les WordPress connectés/autorises de clients CRM actifs et actives pour Tech. Sites externes admissibles si Connector autorise.
- **Securite :** SSL/DNS en lecture seule depuis Alliance (public IP uniquement, sans acces aux IP privees); WP-Cron/SQL en lecture seule sur le site et synthese expurgee envoyee au canal Connector existant. Aucun mot de passe, contenu SQL, argument de tache ni changement de DNS n est collecte.
- **Alertes :** dates SSL 30/14/7 jours, changements DNS apres confirmation, erreurs TLS transitoires recontrolees sur deux passages distants d au moins 15 minutes. Pas de courriel CRITICAL direct.
- **UX :** tableau lisible clair/sombre et responsive dans Monitoring avec controle manuel SSL/DNS par site; resume dans la fiche Tech. Mesures anciennes/absentes = En attente/A verifier, jamais OK invente.
- **Compatibilite :** source Suite 4.5.386; autres composants byte-for-byte identiques. Les agents clients 1.10.10 restent fonctionnels, mais telemetrie WP-Cron/SQL disponible apres installation Tech 1.10.11 sur les sites.
- **Limites :** sans test sur vrai WordPress (production) et sans confirmation publique en ligne. Pas encore de scan DKIM (selector inconnu), diagnostic des hooks bloquants et SQL lent, ni test synthetique Elementor.
- **Documents :** README, CHANGELOG, ROADMAP, validation et journal de Suite synchronises.

# Tech AWM 1.10.10 — sites WordPress réellement gérés — 2026-10-11

- La page **Protection formulaires** inclut uniquement les sites appartenant à un client **actif dans CRM AWM** ET disposant d’un **Core Site Connector / Hub Client autorisé, non révoqué**. Un domaine conservé pour SEO, Ads, comptabilité ou un autre service ne suffit pas.
- Le lieu d’hébergement n’est jamais un critère : un WordPress externe connecté reste éligible. Un site déconnecté, jamais appairé ou révoqué est absent des listes et compteurs.
- Même filtrage pour propagation globale, synchronisation cron, Appliquer et Vérifier. Le droit du Connector est revérifié juste avant chaque requête distante.
- Aucune suppression : l’historique et les modes particuliers sont conservés jusqu’à une éventuelle reconnexion. Aucune modification de la logique Elementor, des courriels, de CallTracker, de la surveillance HTTP ni des sondes.
- Statut opérationnel CRM et Connectors Core existants réutilisés sans nouvelle table SQL ni logique d’hébergement présumée.
- Validation : tests PHP isolés, contrôle PHP/JS et ZIP; valider sur un site WordPress réel avant propagation massive.

# Tech AWM 1.10.9 — Respect du statut actif CRM dans Protection formulaires — 2026-10-11

- Liste, métriques et propagation anti-spam limitées aux clients opérationnels selon CRM AWM (non-actifs, archivés et supprimés exclus).
- Validation du statut au moment de l'appel distant et avant la vérification manuelle, même après une modification de statut concurrente.
- Le cron ignore les entrées historiques inactives lors du calcul du prochain réveil, sans les supprimer : restauration possible après réactivation.
- États vides et libellés actualisés pour afficher uniquement les sites des clients actifs.
- 17 tests de contrat locaux réussis; PHP lint, checksums ZIP et manifest vérifiés. Aucun changement de schéma SQL.
- Comportement du Honeypot/Elementor, email client, LeadTracker, Tech monitoring, CSS, Core/Hub/CRM et 10 autres archives Suite inchangé.

# Tech AWM 1.10.8 — Protection formulaires : harmonisation UX / CSS — 2026-10-11

- Harmonisation de **Tech AWM → Protection formulaires** avec les surfaces, bordures, typographies et variables clair/sombre du shell AWM, sans styles codés en blanc.
- En-tête Tech / Sécurité, indicateurs lisibles, sections « Protection par défaut » et « Protection par site » avec instructions courtes.
- Liste compacte de 84+ sites au lieu de grandes cartes en deux colonnes, états explicites, version Hub Client, compteurs issus du dernier relevé, diagnostics d'erreur.
- Recherche client/domaine avec accents, filtres des états, pagination locale 15/30/60 et état vide informatif, sans appel AJAX supplémentaire.
- Boutons **Appliquer** et **Vérifier** restent distincts et liés au bon client_id/site_id et à leurs nonces; choix global et exception par site préservés.
- Retour à la ligne de travail après une action par site dans le même onglet grâce au stockage temporaire du filtre/page, sans ajouter le nom du client à l'URL.
- Responsive tablette/mobile sans défilement horizontal et sans texte illisible; meilleure accessibilité (labels, focus clavier, contrastes, préférence réduction des animations).
- Un garde-fou de compatibilité conserve **Tech 1.10.7** comme version minimale du runtime client : une mise à jour d’interface sur le Hub ne force pas la mise à niveau de 84 agents clients.
- **Aucun changement** aux règles anti-spam, à la validation Elementor, au routage des courriels/LeadTracker, à Hub Client, aux sondes HTTP, aux permissions, à Recovery ou au CPL.
- Tests locaux de rendu PHP sur 84 sites simulés et vérifications navigateur Chromium en modes sombre/clair, bureau/tablette/mobile. Validation en production WordPress et Elementor Pro à confirmer.

# 1.10.7 — 2026-10-11 — correctif alertes CRITICAL trompeuses
- Correctif de la double vérification immédiate : les probes rapprochées ne confirment plus une panne.
- Confirmation dans des passages WP-Cron distincts avec bornes 90–1800 s; au moins 3 contrôles/210 s pour les échecs sans HTTP.
- Retry planifié prioritaire pour anomalies récentes; capacité de rotation préservée pour les autres clients.
- GET avec limite de taille, délai 7 s et sans `Range` / `no-cache`; 403/429 classés en avertissement.
- Détails SMTP/alertes : code HTTP, erreur WP_Error/cURL, horodatages, durée, URL exacte, note de point de mesure unique.
- Fiche Tech et timeline : erreur technique et horodatage lisibles; pas de message « hors ligne » non confirmé.
- Dédoublonnage des courriels répétés 30 minutes pour l'incident HTTP, sans supprimer son journal.
- Aucun changement de schéma SQL, Hub Client, antispam Elementor, CPL ni moteur Recovery.
- Lint PHP + tests isolés : PASS. Tests sur le site euro-spa.com et WordPress réel : non effectués.

# 1.10.6 — 2026-10-11 — pilotage central Elementor Form Guard
- Nouveau menu Tech AWM > Protection formulaires, affichage réactif par site/client avec recherche.
- Mode global et exceptions locales au site, sauvegarde nonce + permission admin Hub.
- Déploiement en petites tranches via le canal Core/Hub Client existant, jamais via endpoint public ni accès WP admin du client.
- Réponse confirmée par client_id/site_id/instance_uuid + mode, et diagnostics explicites en cas d'échec.
- Télémétrie agrégée (passages, blocages, faux positifs à surveiller), sans PII.
- Découverte quotidienne des nouveaux sites et reprise non-bloquante des sites encore hors ligne.
- Aucune modification de Recovery, Autopilote ou des modules CallTracker/CPL.
- Tests isolés du pilotage et des identités : PASS; validation end-to-end sur WordPress réels requise.

# 1.10.5 — Tech systeme par defaut — 2026-10-01
- Tech est actif par defaut pour tout identifiant client valide; la resolution CRM temporairement indisponible ne vaut plus desactivation.
- Seule une action humaine enregistrant `_awm_thech_enabled=0` desactive Tech durablement.
- Compatible avec Core 4.5.262 qui installe, active et met Tech a niveau avant Recovery.

# 1.10.3 — canal autonome de réactivation Hub Client — 2026-09-28
- Ajoute `awm-tech-rescue/v1/hub-client/reactivate`, disponible sans runtime Hub Client.
- Authentification stricte par le secret de scan local chiffré déjà synchronisé avec Core.
- L action est limitée au plugin canonique `hub-client-awm/hub-client-awm.php`; aucun slug arbitraire n est accepté.
- Respecte le scope site/réseau mémorisé par la configuration de migration MU lorsque disponible.
- Journalise uniquement le résultat et les versions, jamais le secret.
- Cette route rétablit le canal de gestion; elle ne déploie aucune mise à jour et ne modifie pas les gardes Recovery.

# 1.10.2 — autopilote extensions observable et réveil immédiat — 2026-09-25
- Activer une politique `Automatique` déclenche maintenant un premier passage immédiat au lieu d attendre jusqu à une heure.
- Ajoute un watchdog et un état persistant : dernier passage, réussites, erreurs, blocages Recovery, inventaires rafraîchis et prochain passage.
- Le worker rafraîchit l inventaire WordPress avant d agir et conserve le `fleet_state` Recovery reçu du Hub Client.
- Un site sans `recovery_ready_for_auto` est compté `Bloqué Recovery`, pas comme une erreur opaque.
- Le profil Tech central conserve désormais `fleet_state` et `intervention_preflight` au lieu de les perdre pendant la sanitisation.
- Le correctif d authentification temporaire Elementor 1.10.1 est intégralement conservé.

# 1.10.1 — passage WordPress automatique pour intervention Tech — 2026-09-24
- Corrige le cas observé sur Canevas Rive-Sud où **Elementor avancé** validait le site, Hub Client/Tech et la session sécurisée, puis tombait sur `wp-login.php` faute de cookie WordPress.
- La préparation Elementor retourne maintenant un passage à usage unique via `wp-login.php`; Tech valide le handoff, le `site_id`/instance via la session Alliance et la page cible avant toute authentification locale.
- Si le navigateur n est pas déjà connecté au WordPress client, Tech crée un utilisateur temporaire à capacités d édition limitées, ouvre un cookie WordPress borné par l expiration de la session Tech puis redirige vers Elementor sans demander de mot de passe.
- Le compte temporaire possède un mot de passe aléatoire jamais exposé, est journalisé, expire avec la session et est supprimé automatiquement avec réattribution des éventuels médias/contenus à un administrateur réel.
- **Intervenir sur le frontend** bénéficie du même bootstrap si aucun utilisateur WordPress n est déjà connecté; les contrôles `client_id + site_id + instance_uuid + domaine + page + scope design` restent obligatoires.
- Compatibilité conservée avec le fallback Hub Client historique : si WordPress redirige encore un ancien `editor_url` vers la page de connexion, Tech sait récupérer le handoff depuis `redirect_to`.
- La refonte UX Mises à jour de 1.10.0 est conservée intégralement.

# 1.10.0 — centre de mises à jour guidé — 2026-09-24
- Refonte complète de **Tech AWM > Mises à jour** pour un usage stagiaire : trois espaces distincts **À faire maintenant / Installer / Avancé**.
- Les mises à jour sont regroupées par site avec un seul bouton principal **Mettre à jour ce site**, puis le détail des extensions en second niveau.
- Les sites sans mise à jour sont repliés pour réduire le bruit visuel.
- L'installation de nouveaux modules utilise un seul sélecteur global **Site de destination** au lieu d'un grand menu répété dans chaque carte.
- Les modules AWM et les extensions WordPress approuvées sont séparés et présentés dans des blocs progressifs.
- Les politiques automatiques, l'inventaire complet, les versions Suite et WordPress/thèmes passent dans une **Zone avancée** repliée.
- Ajout d'une navigation mémorisée, d'une cible d'installation mémorisée et d'un flux de mise à jour site par site avec revérification d'inventaire.
- Responsive revu pour éviter les grands menus et rendre les tableaux de détails lisibles sans imposer de barre horizontale dans le parcours principal.

# 1.9.4 — mises à jour tierces directes via Hub Client — 2026-09-23
- Supprime la dépendance implicite à `AWM_Core_Recovery_Library` pour lancer une mise à jour tierce.
- Tech appelle maintenant directement la route Hub Client `tech/plugin/update` avec `client_id + site_id + plugin_file + target_version + operation`.
- Les états `review_required`, `rolled_back` et échecs protégés sont remontés comme erreurs au lieu d être affichés comme succès.
- Les boutons indiquent **Mettre à jour protégé** et rappellent que les extensions premium utilisent la licence du site.

## 1.9.3 - Session glissante + réécriture texte déterministe - 2026-09-23
- La session d intervention se renouvelle de 20 minutes à chaque activité authentifiée, avec plafond dur de 4 heures depuis sa création.
- Le cookie HttpOnly local suit la nouvelle expiration afin que la navigation frontend ↔ Elementor ne tombe plus après 20 minutes d utilisation active.
- Les demandes rédactionnelles explicites sur un widget sélectionné utilisent un moteur déterministe : Tech choisit lui-même le champ Elementor puis demande uniquement la valeur finale au modèle.
- Les intentions SEO, reformuler, raccourcir, allonger, développer, simplifier, corriger, ton vendeur/professionnel et rédaction sont couvertes.

## 1.9.2 - REST same-site www/apex stable - 2026-09-23
- Corrige le cas ou l editeur WordPress est ouvert sur le domaine apex alors que `rest_url()` pointe vers l alias `www` (ou inversement).
- Le client Tech compare les hote canoniques; pour un alias `www`/apex du meme site, il conserve le chemin REST mais utilise l origine actuellement ouverte dans le navigateur.
- Les appels REST utilisent `credentials: include`, `X-WP-Nonce`, le jeton Alliance, la surface et l URL courante.
- Le panneau sante reutilise le meme transport authentifie; aucun second client REST non nonce ne subsiste.
- Les controles serveur `current_user_can(edit_post)`, session Alliance, site_id et instance_uuid restent inchanges.

## 1.9.1 - authentification REST persistante frontend / Elementor - 2026-09-23
- Corrige `awm_tech_target_forbidden` lors du passage d une session Frontend vers l editeur Elementor.
- Les appels REST de la fenetre Tech transmettent maintenant le nonce WordPress `wp_rest` en plus du jeton prive Alliance.
- WordPress conserve ainsi l utilisateur courant sur `/wp-json/` et `current_user_can('edit_post', ...)` reste verifiable au lieu de retomber sur l utilisateur 0.
- Le controle de permission n est pas assoupli : utilisateur connecte + droit d edition + session Alliance + site_id/instance_uuid restent obligatoires.
- Le moteur Elementor generalise de 1.9.0 est inchangé.

## 1.9.0 - moteur Elementor generalise - 2026-09-23
- Généralise l intervention ciblée aux widgets, containers, sections et colonnes.
- Ajoute un planner IA minimal basé sur les capabilities exactes de l élément sélectionné.
- Prend en charge les transformations texte naturelles, images directes/images de fond et réglages layout/style réversibles.
- Les widgets tiers restent fail-closed : seulement réglages universels sûrs, jamais de repeater/formulaire arbitraire.
- Toutes les écritures conservent SHA-256, snapshot et rollback.

## 1.8.6 - reecriture ciblee fiable et icone reglages visible - 2026-09-23
- Corrige le cas ou une demande redactionnelle sur un widget selectionne arrivait jusqu au modele mais terminait sans action exploitable.
- Ajoute un repli IA minimal specialise sur le seul champ texte du widget selectionne; l action finale reste `set_setting`, SHA-256 controlee, permissionnee et reversible par snapshot/rollback.
- Le repli est limite aux widgets `heading`, `text-editor` et `button` et ne s active que pour une intention redactionnelle explicite.
- L icone Reglages de la fenetre Frontend utilise maintenant une police symbole systeme explicite pour ne plus apparaitre vide avec la police terminale.
- Conserve les gardes remote_status/permissions de 1.8.5 et le diagnostic detaille de 1.8.4.

## 1.8.5 - restauration de la garde remote_status / permissions - 2026-09-23
- Corrige la régression `Call to undefined method AWM_Hub_Client_Tech_AWM::remote_status()` observée pendant une conversation Frontend.
- Restaure les deux gardes internes `remote_status()` et `has_permission()` qui existaient en 1.8.1 mais avaient été retirées accidentellement lors du refactor 1.8.2.
- `remote_status()` vérifie maintenant explicitement la disponibilité de `AWM_Hub_Client_Tech_Remote::status()`, intercepte toute exception et refuse les réponses non structurées au lieu de provoquer un fatal PHP.
- Les permissions `chat`, `file_uploads`, `elementor_write` et actions WordPress sûres repassent toutes par la même garde distante fail-closed.
- Aucun changement au format de session, à atomic_v3, Recovery, Core ou à l autopilote.

## 1.8.4 - Contexte widget cible et diagnostic exception par etape - 2026-09-23
- Lorsqu un widget Elementor est selectionne, Tech lit directement ce widget dans `_elementor_data` au lieu de reconstruire toute la page via le moteur Studio avant chaque conversation.
- Le contexte chat selectionne contient uniquement le widget cible, ses champs editables, le hash SHA-256 du document et le contexte minimal du site.
- Si la lecture ciblee echoue proprement, Tech peut encore replier vers le contexte Studio historique sans perdre la session.
- Le pipeline chat est maintenant balise par etapes (`remote_status`, `selected_context`, `payload_encode`, `remote_chat`, etc.) et toute exception journalise et affiche l etape, la classe PHP et le message exploitable.
- Le bouton Diagnostic affiche maintenant la derniere erreur Tech et son contexte plutot qu un simple resume WordPress/PHP.
- Aucune modification du moteur atomic_v3, de Recovery, des permissions ou de l autopilote.

## 1.8.3 - Fenetre Frontend fermee proprement et chat cible compacte - 2026-09-23
- Le bouton X masque desormais le panneau de facon deterministe et ne laisse qu un petit lanceur Tech AWM; les doublons de panneau sont elimines au bootstrap.
- Le CSS force explicitement le panneau ferme a `display:none`, meme apres deplacement ou rejeu des hooks Elementor/theme.
- Lorsqu un element Elementor est selectionne, Tech transmet au chat uniquement le widget cible, ses champs editables et le contexte minimal de page au lieu de toute l arborescence/inventaire.
- Le contexte site retire l inventaire logiciel complet des requetes de conversation, reduisant tokens, taille HTTP et risque de timeout/WAF.
- Les erreurs REST/chat affichent maintenant le code reel et un message exploitable; les erreurs distantes et exceptions sont journalisees dans Tech.
- L appel IA verifie l encodage JSON et remonte le statut/code amont au lieu d une erreur generique.

## 1.8.2 - Navigation frontend persistante pendant une intervention connectée - 2026-09-23
- Une session lancée par **Elementor avancé** peut suivre l administrateur/technicien connecté sur les pages du même site sans perdre la fenêtre Tech.
- La page WordPress courante devient automatiquement la cible d inspection, chat, application et rollback lorsque l utilisateur connecté possède `edit_post` sur cette page.
- La validation distante est recalculée par URL canonique de page et reste liée à `client_id + site_id + instance_uuid`; aucune propagation à un autre site ou répertoire.
- Le frontend transmet explicitement sa surface et son URL courante aux routes privées Tech afin de distinguer navigation frontend et session Elementor stricte.
- Ajout du bouton **Fermer Tech AWM** et d un lanceur compact pour rouvrir la fenêtre sans terminer la session.
- Le `thread_id` de conversation est conservé dans `sessionStorage` pendant la navigation de la même session.
- Un utilisateur WordPress non connecté ou sans droit de modification ne reçoit jamais la fenêtre d intervention.

# Tech AWM 1.8.1 - intervention URL canonique stricte

## 1.8.1 — Elementor avancé / intervention site exact — 2026-09-23
- Corrige le refus `La page d intervention doit appartenir exactement au site jumele` lorsque le site jumelé et WordPress diffèrent uniquement par l alias `www` / domaine apex.
- Le contrôle reste lié à `client_id + site_id + instance_uuid`; aucun autre sous-domaine n est accepté.
- Le port doit rester identique et la cible doit être HTTPS.
- Pour une installation en sous-répertoire, toute page d intervention doit rester dans ce répertoire exact.
- Les chemins encodés contenant `..`, NUL ou séparateur inverse sont refusés avant comparaison.
- Aucun changement au moteur atomic_v3, aux permissions, à Recovery ou au catalogue de modules.

# Tech AWM 1.8.0 - Modules AWM et état Hub Client MU

## 1.8.0 — bibliothèque privée orchestrée par Core — 2026-09-22
- Ajoute le panneau **Modules AWM** dans Mises à jour pour installer ou mettre à jour un module privé sur un `site_id` précis.
- Le catalogue n est pas codé en dur dans Tech : il provient de `AWM_Core_Update_Manager::remote_module_catalog()` et donc de la publication Core active.
- Tech transmet seulement client/site/slug; Core impose la version, le paquet, le SHA-256, l autorisation et la signature.
- Une nouvelle lecture `tech/inventory` est lancée après le déploiement pour confirmer l état réel du site.
- Un module déjà à la version cible est signalé comme déjà à jour et n est pas remplacé inutilement.
- La liste Sites affiche **MU protégé** lorsque Hub Client remonte `must_use=1` avec loader valide.
- La bibliothèque WordPress.org existante reste séparée des modules privés AWM.

# Tech AWM 1.7.40 - Suite 4.5.250

## 1.7.40 — activation sandbox ultra-légère — 2026-09-22
- Pendant `activate_plugin()`, si `WP_SANDBOX_SCRAPING` est actif, Tech définit uniquement ses constantes, enregistre son hook d activation minimal puis retourne immédiatement.
- Aucun runtime client/central, filtre, shutdown handler ou classe Elementor n est enregistré dans cette requête d activation.
- Le chargement complet reprend uniquement dans la requête PHP suivante, après activation réussie.
- Ce correctif complète Hub Client 1.11.51 qui sépare installation et activation en deux requêtes.

# Tech AWM 1.7.39 - Suite 4.5.248

## 1.7.39 — bootstrap client résilient après mise à jour distante — 2026-09-22
- Corrige le pilote Allo Déménagement : Hub Client 1.11.50 s installe, mais la première requête après remplacement de Tech pouvait répondre par la page WordPress « erreur critique ».
- Le runtime client Tech n est plus chargé pendant `plugins_loaded`; il est démarré plus tard avec garde `Throwable` et classes anti-doublon.
- Les requêtes privées Hub Client `update/status`, `update/apply` et `update/rollback` restent volontairement légères : elles exposent la version Tech sans charger le runtime Elementor complet.
- Une erreur de bootstrap Tech est mémorisée localement sans chemin serveur absolu afin de protéger le site et faciliter le diagnostic suivant.
- Les fonctions Tech/Elementor restent chargées sur les requêtes normales, REST Tech, admin et frontend; aucune permission ni signature n est assouplie.
- L autopilote Recovery reste suspendu.

# Tech AWM 1.7.38 - Suite 4.5.243

## 1.7.38 — Accès au site manuel compatible Recovery suspendu — 2026-09-22
- Le clic administrateur **Accès au site** est maintenant traité comme une intervention manuelle explicite.
- Si Hub Client ou Tech doit être préparé avant l ouverture de la session, Tech appelle Core avec `manual=true` et le `site_id` exact.
- Le chemin manuel conserve canal signé, SHA-256, sauvegarde/rollback fichiers et vérification de version.
- L autopilote reste suspendu et aucun déploiement implicite ne contourne Recovery.
- Correction pertinente après migration d hébergement : une preuve RESTORE_TEST peut être invalide sur la nouvelle topologie, sans empêcher une intervention manuelle protégée.

# Tech AWM 1.7.37 - Suite 4.5.235

## 1.7.37 — Etat Recovery exploitable par le Tech — 2026-09-15
- Les cartes Recovery du parc distinguent route de secours, périmètre de sauvegarde et vrai test de restauration.
- `Recovery prêt` ne signifie plus que l'URL répond : l'interface montre explicitement si l'automatisation reste interdite.
- Aucun changement de privilège : un Tech AWM reste administrateur par défaut, avec restrictions explicites possibles.

Date : 2026-09-15

Boutons Recovery relies aux identites nominatives via Core, acces aux portes clientes deja verifiees meme si WordPress est maintenant indisponible. Moteur de mise a jour protege sur version cible exacte et suivi de resultats. Bibliotheque centrale accessible depuis Core.

Retention: version courante + cinq precedentes; sauvegardes completes: cinq. Pas de comptes generiques Tech 1/Responsable. Aucune migration destructive de donnees metier.

Candidate de stabilisation. Aucun deploiement effectue. Recette reelle WordPress + MySQL/MariaDB + PHP-FPM/OPcache + HTTPS et watchdog systeme obligatoire avant activation. Autopilote Suite AWM toujours suspendu. Les paquets des nouvelles mises a jour tierces proviennent encore du fournisseur WordPress de chaque site; leur telechargement unique depuis Alliance reste au roadmap.

## Historique

## 1.7.35 — Recovery AWM integre au poste Tech — 2026-09-14

- Bouton Recovery compact dans l en-tete Tech et nouveau sous-menu Recovery.
- Inventaire des portes Recovery du Hub central et des sites Hub Client a partir du dernier `fleet_state` valide.
- Bouton Recovery dans les cartes/fiches de site et la liste Sites lorsque l URL de secours a ete annoncee.
- Aucun mot de passe Recovery ni secret serveur n est stocke dans Tech; l authentification reste celle de la porte externe.
- UX niveau 1 documentee : dernier stable cible uniquement; points plus anciens et BD reserves au responsable.

## 1.7.34 — Morning Brief Health transversal — 2026-09-12

- Le Brief AWM affiche le score Health Suite /100 et ses raisons de vigilance tout en conservant incidents, SLA et priorités comme autorités opérationnelles.
- Le score Health est rafraîchi avec le snapshot du cockpit et reste strictement informatif.

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

- Expose au Core un pulse incidents ouverts / critiques afin d alimenter la santé système transversale.
- Le pulse est en lecture seule et ne remplace pas les préflights, actions recommandées ou preuves Tech.

# Tech AWM 1.7.32 — préflight intervention, tournée Tech et capacité

- **Livré** : la fiche Tech affiche un préflight avant intervention à partir des preuves runtime disponibles : Connector, permissions d écriture WordPress et comportement OPcache.
- **Livré** : un état inconnu reste explicitement **À vérifier**; Tech ne déduit jamais qu un site est prêt lorsqu une preuve manque.
- **Livré** : la fenêtre Incidents regroupe les incidents par **client + site** dans une tournée Tech suggérée, triée par score maximal puis incidents nouveaux, afin de réduire les changements de contexte.
- **Livré** : une vue **Capacité Tech** montre ouverts, nouveaux, sites concernés, plus ancien incident, SLA dépassés/à risque et score maximal par responsable, avec un bloc Non assigné distinct.
- **Sécurité** : aucune réaffectation ni action sensible n est automatique; le préflight n expose aucun chemin serveur, secret Connector ou clé API.
- **Gouvernance** : ROADMAP, CHANGELOG, notes et validation/logs sont synchronisés avec Suite AWM 4.5.229.

# Tech AWM 1.7.31 — priorisation opérationnelle et historique étendu

- **Livré** : chaque incident reçoit un score opérationnel transparent `impact × urgence × confiance`, normalisé sur 100, sans masquer la criticité brute.
- **Livré** : la fenêtre Incidents affiche le score, ses trois composantes et une file d actions recommandées contextuelles (prise en charge, fiche Tech, Sécurité, note, résolution après vérification).
- **Livré** : les incidents ouverts sont ordonnés par score opérationnel, puis criticité et récence afin que le Tech traite d abord les situations les plus importantes.
- **Livré** : la fiche Tech possède maintenant un historique basculable **24 h / 7 j** pour les sondes, incidents, actions, formulaires et mises à jour déjà journalisés, sans dupliquer le moteur Stats.
- **Gouvernance** : roadmap, changelog, notes et validation/logs restent obligatoires et synchronisés avec Suite AWM 4.5.228.

# Tech AWM 1.7.30 — accélération opérations et observabilité

- **Livré** : filtres Client et Site dans les fenêtres Priorités du parc et Incidents, en plus des filtres criticité/signal/workflow; les choix restent mémorisés pendant la session.
- **Livré** : les sites avec incident ouvert passent en priorité dans chaque lot de sondes, sans dépasser la limite globale de 12 sondes par cycle; le round-robin normal continue pour le reste du parc.
- **Livré** : Wordfence Intelligence conserve les 12 dernières tentatives de synchronisation sans secret, mémorise le dernier succès et classe la fraîcheur en Données fraîches / Cache acceptable / Données périmées / Jamais synchronisé.
- **Livré** : la page Sécurité affiche dernier succès, dernière tentative et historique de synchronisation avec statut HTTP utile.
- **Gouvernance** : roadmap, changelog, notes de livraison et validation sont synchronisés avec Suite AWM 4.5.227.

## Tech AWM 1.7.29 — diagnostic Wordfence V3 clair et non bloquant

- Le refus Wordfence Intelligence n ouvre plus une fenêtre globale bloquante : l état apparaît directement dans le panneau Sécurité et le reste de la page demeure utilisable.
- Un HTTP 401 est identifié explicitement comme **clé Wordfence Intelligence V3 refusée** et explique que la clé doit provenir de **Wordfence > Account > Integrations**, pas de la licence du plugin Wordfence installée sur un site.
- Le panneau propose **Retester maintenant**, **Configurer la clé** et **Wordfence Integrations** sans exposer le secret et sans distribuer la clé aux sites clients.
- Le KPI Journal gratuit distingue désormais **Actif**, **Clé refusée**, **À vérifier** et **À configurer** au lieu d afficher Actif dès qu un secret existe.
- Les erreurs 429, réseau ou réponse invalide restent non bloquantes et conservent le dernier diagnostic utile; aucun faux résultat de vulnérabilité n est inventé.
- Le bloc de diagnostic suit la typographie personnelle Tech et reste responsive.
- ROADMAP, CHANGELOG, notes de livraison et rapport de validation sont synchronisés avec la version.

## Tech AWM 1.7.28 — alertes actionnables, overlays lisibles et Moniteur personnalisable

- Toutes les annotations de **Priorités du parc** liées à un site sont maintenant entièrement cliquables, pas seulement les situations corrélées : cliquer n importe où sur une ligne ouvre la fiche Tech complète du site.
- La fiche ouverte depuis une alerte fournit le résumé technique existant et ses actions contextuelles : ouverture du site, détails techniques, contrôles, Connector, mises à jour ou autres actions déjà autorisées selon l état réel du site.
- Les lignes cliquables affichent un indice visuel et une indication **Cliquer pour le résumé complet et les actions**; les actions sensibles conservent leurs confirmations et permissions existantes.
- La **Typographie dashboard** personnelle s applique désormais aussi aux fenêtres Tech, notamment **Priorités du parc**, filtres, annotations, résumés, historiques, boutons d intervention et fiches site ouvertes en overlay.
- Le **Mode moniteur** utilise maintenant le même moteur de personnalisation de blocs que le dashboard : visibilité, ordre, drag & drop, grille 12 colonnes et largeurs 1/4, 1/3, 1/2, 2/3, 3/4 ou pleine largeur.
- La disposition du Moniteur est indépendante de celle du dashboard et reste enregistrée par `user_id`; un Tech peut donc construire un écran mural différent de son poste de travail.
- La **Typographie Moniteur** conserve la priorité en Mode moniteur, y compris lorsque les blocs sont redimensionnés ou déplacés.
- ROADMAP, CHANGELOG, notes et rapports de validation sont synchronisés avec cette livraison.

## Tech AWM 1.7.27 — édition de grille sans panneau superposé

- Quand le Tech choisit le préréglage **Personnalisée**, le panneau de personnalisation se ferme automatiquement afin de rendre tout le dashboard disponible pour le drag & drop.
- Un bouton **Déplacer les blocs** permet aussi d entrer directement dans ce mode lorsque la disposition enregistrée est déjà personnalisée.
- Pendant le déplacement, une barre compacte reste en bas de l écran avec **Annuler** et **Enregistrer mon tableau**; le panneau flottant ne masque plus la carte ni les autres blocs.
- Ouvrir de nouveau l icône Personnaliser met le déplacement en pause sans perdre la disposition de travail; fermer le panneau sans sauvegarder restaure les préférences enregistrées.
- Les raccourcis, blocs visibles, typographie, profils 1080p/4K, grille 12 colonnes et responsive interne restent sauvegardés par `user_id`.

## Tech AWM 1.7.26 — dropdown de liens, blocs container-responsive et typo des fiches

- `Liens personnalisés` devient un dropdown compact directement dans la zone d actions de l en-tete Tech, avant Personnaliser et Light/Dark; les raccourcis ne consomment plus de largeur en permanence.
- `Fermer` du panneau Personnaliser devient un vrai bouton compact avec icone, cohérent avec le reste du shell.
- La Carte utilise maintenant la largeur réelle de son bloc : les périodes se réorganisent en 4 puis 2 colonnes au lieu de déborder sur le bloc voisin.
- `État des sites` abandonne le défilement horizontal lorsque la colonne devient insuffisante : chaque ligne se transforme automatiquement en carte avec libellés, puis en pile verticale sur les petites zones.
- Les blocs étroits utilisent des container queries : la décision de passer en mode compact dépend de la largeur du bloc 1/4, 1/3, 1/2, etc., pas seulement de la largeur globale du navigateur.
- La **Typographie dashboard** personnelle suit maintenant aussi la fiche Tech, ses onglets, métriques, SEO, WordPress, sécurité, historique, boutons et cartes de sites; l échelle reste propre à chaque `user_id`.
- Les préférences par `user_id`, la grille 12 colonnes, les ratios, le drag & drop, les profils 1080p/4K et les données de monitoring restent inchangés.

## Tech AWM 1.7.25 — en-tete compact et dropdown Dark

- Les raccourcis personnels quittent la grande barre sous le shell et sont maintenant injectes directement dans l en-tete Tech, a cote du contexte du module.
- Le bouton Personnaliser devient une icone compacte placee immediatement a gauche du bouton Light/Dark; la rangee supplementaire du dashboard est supprimee.
- Les raccourcis restent propres a chaque `user_id`, defilent horizontalement si l espace devient trop etroit et ne forcent plus une carte pleine largeur en hauteur.
- Le dropdown Prereglage et tous les selects du panneau Personnaliser utilisent maintenant un schema de couleur natif coherent en Dark et Light; les options ne peuvent plus apparaitre blanc sur blanc.
- Aucun changement au moteur grille 12 colonnes, aux ratios, au drag & drop, aux donnees de monitoring ni aux Connectors.

## Tech AWM 1.7.24 — grille responsive personnalisable

- Le dashboard utilise maintenant une grille 12 colonnes avec ancrage automatique et largeurs 1/4, 1/3, 1/2, 2/3, 3/4 ou pleine largeur.
- Chaque Tech peut déplacer les blocs directement en mode Personnaliser; le drag & drop réordonne la grille sans positionnement libre au pixel près.
- Chaque bloc conserve sa largeur et son ordre par `user_id`; un Tech peut donc afficher Visites verticalement en 1/3 tandis qu un autre l affiche horizontalement en 3/4.
- Les blocs changent leur présentation interne selon leur largeur : Top sites peut s étaler sur deux colonnes, KPI se recompone, Timeline et Carte deviennent compactes lorsque leur zone est étroite.
- Pour les paires Carte/Visites et Timeline/Incidents, une largeur 3/4 ajuste automatiquement le compagnon à 1/4 (et 2/3 à 1/3) lorsque les deux blocs sont voisins, afin de remplir proprement la rangée.
- Le responsive protège la mise en page : ratios personnels conservés sur bureau/1080p/4K puis empilement automatique lorsque l écran devient trop étroit.
- La taille de typographie personnelle est appliquée aussi aux textes secondaires du dashboard afin d éviter les éléments qui restent minuscules.
- Un bouton Réinitialiser la grille restaure la disposition AWM standard 2/3 + 1/3.

## Tech AWM 1.7.23 — flotte, bibliothèque et dashboard personnel

- Gestion globale Automatique/Manuel des extensions tierces actives et bouton Tout mettre à jour avec confirmation succès/échecs.
- Boutons de mise à jour harmonisés au CSS des autres actions Tech.
- Bibliothèque AWM initiale d extensions WordPress.org approuvées, installables à distance sur un site Hub Client connecté.
- Dashboard personnalisable par utilisateur Tech : blocs visibles, raccourcis personnels, disposition Standard/Carte en premier/Sites en premier, taille de typo réglable finement, profil Moniteur Auto/1080p/4K et taille Moniteur.
- Préférences enregistrées par utilisateur via AJAX, sans rechargement de page.
- La roadmap publique reste obligatoire et synchronisée avec la publication Suite active.

# Tech AWM 1.7.22 — Économiseur Chromecast + actions AJAX

- Ajoute **Économiseur** dans la barre du Mode moniteur pour démarrer l écran de veille immédiatement.
- Corrige l activation automatique pendant un cast Chromecast : les petits événements `pointermove` parasites ne réinitialisent plus continuellement l inactivité.
- **Réveil sur critique** réagit maintenant à une nouvelle transition critique; un incident déjà critique n empêche plus l économiseur de démarrer.
- `Vérifier maintenant`, le diagnostic `À vérifier`, les mises à jour d extensions et l enregistrement du Mode moniteur utilisent AJAX lorsqu un contexte précis de site est disponible.
- Ajoute **Mettre à jour les X** pour exécuter séquentiellement les mises à jour WordPress tierces disponibles puis revérifier le site une seule fois.
- Les actions gardent leur fallback serveur classique quand un contexte AJAX sûr n est pas disponible.

- Le CSS premium du bloc Mode moniteur / économiseur est appliqué à tous les formulaires de la page Réglages Tech.
- Cartes, champs, listes déroulantes, aides et barres d action utilisent désormais le même contraste, la même densité et les mêmes hauteurs.
- Les boutons Enregistrer des autres sections reprennent la barre d action du Moniteur sans devenir sticky, afin d éviter des superpositions pendant le défilement.
- Responsive : les grilles de réglages passent proprement sur une colonne sous 900 px.

# Tech AWM 1.7.20 — statuts de fiche actionnables et actions alignées

- Dans les fiches techniques multi-sites, **À connecter** devient cliquable et mène directement au Connector exact du `site_id` dans la fiche CRM.
- **À vérifier** devient une action réelle : si le site est connecté, le clic relance immédiatement l inventaire et le diagnostic d indexation; sinon il mène au Connector requis.
- Après **Vérifier maintenant**, le retour se fait sur la fiche du site concerné plutôt qu en haut de la page.
- **Vérifier maintenant** et **Ouvrir le site** utilisent maintenant exactement la même hauteur, le même alignement vertical et une icône centrée.
- Aucun changement au moteur de sondes, aux données SEO, aux mises à jour tierces ou au canal signé Core.

# Tech AWM 1.7.19 — fiches multi-sites, vérification immédiate et Moniteur fiabilisé

- Chaque site CRM, principal ou secondaire, possède sa propre fiche technique avec URL complète exacte, `site_id`, état, indexation et inventaire WordPress.
- **Vérifier maintenant** force un contrôle WordPress frais : état, indexation et disponibilités de mises à jour.
- Une mise à jour tierce détectée peut être lancée immédiatement depuis la fiche avec le chemin sécurisé existant, sauvegarde et rollback; les modules AWM restent sur le canal Core.
- Le bouton **Enregistrer le Mode moniteur** utilise désormais une action admin dédiée, confirme la sauvegarde et revient directement au panneau Moniteur.
- Les listes/réglages Moniteur et les inventaires plugins gagnent contraste, espacements et typographie pour rester lisibles en Dark.

## 1.7.18 — 2026-09-12
- Mode moniteur épuré : masque le shell Tech, le titre Vue globale et les badges de contexte/surveillance pour maximiser les données utiles au cast.
- Typographie agrandie en Mode moniteur pour KPI, priorités, carte et Top sites afin de rester lisible à distance.
- Bouton Light/Dark déplacé dans la barre de la carte en Mode moniteur.
- Ajoute un économiseur d écran navigateur configurable (1/5/10/30 min, minimal/opérationnel/rotation, luminosité, plage nuit).
- L économiseur affiche heure/date et état opérationnel, dérive lentement pour limiter le marquage et réveille le dashboard automatiquement sur incident critique si configuré.

## 1.7.17 — 2026-09-11

- En-tête de carte compact : compteur visites, périodes et Mode moniteur sont regroupés sur une seule barre.
- Suppression de la légende explicative et des tuiles de sites au-dessus de la carte; Top sites aujourd’hui devient la légende visuelle opérationnelle.
- Mode moniteur déplacé dans la barre de carte pour un accès direct au plein écran/cast.
- Carte agrandie verticalement afin d’utiliser l’espace récupéré, avec repli responsive à 1500 / 1100 / 782 px.
- Aucun changement au moteur GeoIP, aux teintes client/site, aux popups, au graphique intégré ni au polling.

## 1.7.16 — 2026-09-11
- Refonte la fiche Tech en console opérationnelle avec hiérarchie visuelle claire et densité accrue.
- Ajoute un en-tête compact avec rôle Principal/Secondaire, URL cliquable, score, disponibilité, indexation et actions principales.
- Ajoute une barre Santé du site sur une ligne : disponibilité, HTTP, indexation, vulnérabilités, mises à jour, versions Hub/Tech et dernier contact.
- Ajoute une zone **À faire** qui remonte seulement les anomalies/action recommandées; si aucun signal n exige d action, la fiche affiche un état calme.
- Ajoute les onglets **Vue d’ensemble / SEO / WordPress / Sécurité / Historique** afin d éviter une longue fiche technique verticale.
- La Vue d’ensemble présente trois cartes compactes : Santé technique, SEO essentiel et WordPress & maintenance.
- L onglet WordPress conserve l inventaire complet et ajoute les filtres Tous / À mettre à jour / Auto / Manuel / Inactifs.
- L onglet Sécurité résume alertes, vulnérabilités, criticité, transport et dernier contact; l Historique devient compact lorsqu il est vide.
- Renomme l action d accès complet en **Détails techniques** et évite de dupliquer un second footer d action dans le popup.
- Aucun changement de sonde, incident, Connector, données SEO, politique de mise à jour ou historique.

## 1.7.15 — 2026-09-11
- Renomme le Mode TV en **Mode moniteur** et l ouvre dans une fenêtre dédiée réutilisable, sans navigation WordPress, pour affichage plein écran/cast.
- Synchronise la couleur des rangs Top sites : numéro, nom et barre reprennent exactement la teinte du site sur la carte.
- Rend l URL complète cliquable dans le popup cartographique et dans la fiche Tech, avec ouverture dans un nouvel onglet.
- Enrichit la fiche Tech avec Index/No-index, source, HTTP final, URL finale, canonical, robots.txt, sitemap XML, directives robots et follow/nofollow.
- Ajoute la liste complète des extensions WordPress dans la fiche Tech avec version, état, mise à jour et politique Auto/Manuel/Canal AWM.

## 1.7.14 — 2026-09-11

- Transforme `Tech AWM → Mises à jour` en inventaire complet des extensions WordPress de tous les sites Hub Client connectés.
- Ajoute un choix `Manuel / Automatique` propre à chaque `client_id + site_id + plugin_file` et un bouton `Mettre à jour maintenant` pour les extensions tierces avec mise à jour disponible.
- L automatisation traite un nombre limité d extensions par passage horaire et ignore les clients CRM inactifs.
- Les modules AWM sont identifiés comme `Canal AWM` et ne peuvent jamais être mis à jour par le moteur générique WordPress.
- Ajoute dans la fiche Tech et la liste Sites un diagnostic `Indexable / No-index / À vérifier` fondé sur `blog_public`, `X-Robots-Tag`, la meta robots de l accueil et `robots.txt`, avec motif visible.
- La carte du Centre d opérations utilise une famille de couleur déterministe par client et une teinte différente pour chaque site du même client.
- La légende, les infobulles et popups indiquent `Principal / Secondaire` et l URL complète exacte du site, incluant sous-domaine et sous-dossier lorsqu ils existent.
- Les points de plusieurs sites partageant la même localité GeoIP sont légèrement séparés afin que leurs teintes restent visibles.

## 1.7.13 — 2026-09-11
- Compacte le Brief AWM du Centre d’opérations sur une seule ligne de résumé à largeur bureau : état, incidents, MTTD, prise en charge, MTTR, conformité, fenêtres 7/30/90 et accès aux priorités.
- Réduit fortement la hauteur des trois cartes de priorité : padding, badges, typographie et espacement sont resserrés sans supprimer le client, le site, la criticité ni le nombre de signaux.
- Supprime la grande zone vide au-dessus des cartes de priorité et remonte la carte GeoIP / activité temps réel dans le premier écran.
- Conserve un repli responsive : la ligne SLA peut passer sous le titre à largeur intermédiaire et les priorités reviennent en une colonne sur mobile.
- Aucun changement de données, sondes, incidents, SLA, GeoIP, Connector ou historique.

## 1.7.12 — 2026-09-11
- Corrige la régression du Centre d’opérations qui empêchait l’initialisation de la carte Leaflet et de la courbe après l’ajout des fenêtres SLA 7/30/90.
- Cause corrigée : le helper numérique `num()` était appelé pendant l’initialisation SLA avant la création de la constante JavaScript correspondante, déclenchant une erreur de temporal dead zone et arrêtant `ops-dashboard.js`.
- `num()` devient une déclaration de fonction hoistée afin que l’ordre d’initialisation soit sûr sans modifier les calculs SLA existants.
- Aucun changement de données, GeoIP, sondes, incidents, SLA, Connector ou historique.
- Ajoute au protocole de validation un smoke test d’exécution du script du cockpit, en plus du simple contrôle de syntaxe JavaScript.

## 1.7.11 — 2026-09-11
- Ajoute les objectifs SLA globaux MTTD / prise en charge / MTTR dans Réglages Tech; `0` signifie explicitement qu aucune cible n est définie.
- Ajoute des surcharges SLA par client puis par `site_id` depuis la fiche CRM → Tech, avec héritage déterministe `site → client → global`.
- Ajoute les fenêtres SLA 7 / 30 / 90 jours dans le Brief AWM, conservées côté navigateur pendant la session.
- Calcule la conformité uniquement sur les incidents possédant une cible explicitement configurée; aucune cible contractuelle n est inventée.
- Ajoute un état SLA par site : `Respecté`, `À risque`, `Dépassé`, `Échantillons insuffisants` ou `Objectif non défini`.
- `À risque` correspond à une moyenne entre 80 % et 100 % de la cible; `Dépassé` signifie une moyenne au-delà de la cible.
- Prépare le raccord futur CRM service/contrat avec le filtre `awm_thech_sla_targets`, sans migration DB ni modification destructive.
- Ajoute une escalade courriel optionnelle pour les incidents `error/critical` qui restent `Nouveau` et non pris en charge après un délai configurable de 5 à 1 440 minutes.
- L escalade est désactivée par défaut, possède ses propres destinataires, ne s envoie qu une fois par incident et journalise `email_escalated` uniquement après un `wp_mail()` réussi.
- Les clients CRM inactifs, incidents résolus ou incidents déjà pris en charge sont exclus automatiquement de l escalade.

## 1.7.10 — 2026-09-11
- Tech AWM consomme le statut canonique CRM : un client inactif disparaît du Centre d'opérations, des sites, du monitoring, de la carte, des priorités et des nouvelles alertes.
- Les sondes cessent pour les clients inactifs; les incidents encore ouverts sont fermés proprement avec un événement système `client_deactivated`, sans suppression d'historique.
- La réactivation CRM reprend automatiquement la surveillance avec les mêmes sites et le même Connector.
- Re-sondage prioritaire immédiat lors d'un premier signal `warning/error` afin de confirmer rapidement l'anomalie.
- Instrumentation MTTD réelle via `first_signal_at`; aucune valeur n'est fabriquée si le premier signal fiable manque.
- SLA 30 jours calculés globalement et par site (MTTD, prise en charge, MTTR).
- Notifications courriel configurables aux techniciens lors de la création d'un incident `error/critical`.

## 1.7.9 — filtres opérationnels et SLA Alliance v1

- Ajoute des filtres rapides dans le popup **Incidents** : état `Nouveau / Pris en charge`, responsabilité `À moi / Non assigné` et criticité `Critique / Erreur / Surveillance`.
- Ajoute des filtres rapides dans le popup **Priorités** : criticité et type de signal `Incident / 404 / Mise à jour / Surveillance`.
- Les filtres restent entièrement côté cockpit : aucune donnée brute n est supprimée et le polling silencieux continue d actualiser la source complète.
- Ajoute un résumé **SLA Alliance · 30 jours** directement dans le Brief AWM, sans créer un nouveau gros bloc vertical.
- Expose le délai moyen de prise en charge, le MTTR moyen, le taux de prise en charge et le nombre d incidents observés sur 30 jours.
- N invente pas de MTTD : tant que l horodatage fiable du premier signal avant confirmation n est pas instrumenté, l indicateur reste explicitement non disponible.
- Aucune migration DB : Tech conserve la DB 1.2.0 et calcule ces mesures à partir des incidents existants.

## 1.7.8 — prise en charge opérationnelle des incidents

- Ajoute le workflow humain `Nouveau → Pris en charge → Résolu` sans casser le statut technique ouvert/résolu utilisé par le moteur automatique.
- Ajoute un responsable Alliance, la date de prise en charge, la durée depuis détection, le temps avant prise en charge et la durée totale de résolution.
- Ajoute des notes internes et un historique append-only par incident avec acteur, horodatage et type d action.
- Le bouton `Prendre en charge` assigne automatiquement l incident à l utilisateur Alliance courant; un incident déjà assigné peut être repris explicitement.
- La résolution manuelle accepte une note et conserve l auteur; si le signal technique reste actif au prochain contrôle, Tech ouvre de nouveau un incident plutôt que de masquer artificiellement une panne réelle.
- Les résolutions automatiques du moteur sont aussi journalisées afin de distinguer clairement intervention humaine et retour à la normale détecté automatiquement.
- La Timeline universelle v1 affiche désormais les prises en charge et notes d incident en plus des ouvertures/résolutions.
- DB Tech passe de 1.1.0 à 1.2.0 avec champs de workflow et table `incident_events`; aucune donnée d incident historique n est supprimée.

## 1.7.7 — en-tête compact fusionné au shell AWM

- Supprime le deuxième bandeau `Centre technique Alliance / Tech AWM / Session réservée`.
- Remonte ces informations directement dans l en-tête principal Tech AWM via le slot sécurisé du shell Core 4.5.179.
- Libère de la hauteur avant les priorités et la carte sans retirer l information de sécurité ni la version.

## 1.7.6 — cockpit compact et densité opérationnelle

- Réduit fortement la hauteur utilisée par l’en-tête, l’état global, la surveillance et le mode TV.
- Conserve les six cartes Priorités / Incidents / 404 / Mises à jour / Formulaires / À surveiller sur une seule ligne lorsque l’écran le permet.
- Retire le microtexte répétitif des cartes sans retirer leur comportement cliquable ni leurs popups.
- Transforme le Brief AWM en bande compacte et conserve les trois situations principales.
- Réduit les espacements d’en-têtes de cartes et des contrôles de période afin de faire remonter la carte et les listes live.
- Conserve l’adaptation responsive : 6 → 3 → 2 → 1 colonne selon la largeur.
- Aucun changement de données, incident, GeoIP, sécurité, Connector ou base de données.

# Changelog Tech AWM

## 1.7.5 — Timeline universelle v1
- Ajoute la timeline opérationnelle des dernières 24 h au Centre d’opérations.
- Aligne incidents ouverts/résolus, sondes anormales, actions Tech, formulaires Stats et mises à jour détectées.
- Ajoute les filtres Tout / Incidents / Tech / Stats / Sondes / Mises à jour.
- Ajoute la chronologie récente à chaque popup de site.
- Conserve `client_id + site_id` et n’invente aucune causalité entre événements.
- Réutilise les tables Tech/Stats existantes; aucune migration DB.
- Conserve le polling silencieux et la carte Leaflet sans flicker.

# 1.7.4 — Brief AWM et corrélation d’incidents v1

- Regroupe les signaux actifs d’un même `client_id + site_id` dans une seule situation prioritaire afin d’éviter les doublons entre incident, 404, mise à jour importante et état à surveiller.
- Conserve toutes les vues brutes séparées : Incidents, 404, Mises à jour et Sites à surveiller restent consultables individuellement.
- Le regroupement ne déduit aucune cause : le popup indique explicitement que plusieurs signaux sont présents sur le même site sans conclure automatiquement à une causalité.
- Trie les situations par sévérité, nombre de signaux puis activité du site afin de faire remonter les cas les plus importants.
- Ajoute un **Brief AWM** sous les cartes d’attention avec état global, résumé du parc et trois situations prioritaires cliquables.
- Le Brief AWM se met à jour avec le polling silencieux existant sans reconstruire la carte ni provoquer de flicker.
- Ajoute au Futur officiel : timeline universelle du site, centre de mises à jour intelligentes, réparation semi-automatique avec snapshot/rollback, SLA/MTTD/MTTR, écran TV client intelligent, Health prescriptif, attribution jusqu’au revenu et couches cartographiques Visiteurs/Clients/Incidents/Formulaires/Revenus/Opportunités.

# 1.7.3 — priorités cliquables et activité live par site

- Remplace les KPI généraux du haut par six cartes opérationnelles cliquables : Priorités, Incidents ouverts, Erreurs 404, Mises à jour importantes, Formulaires aujourd’hui et Sites à surveiller.
- Chaque carte ouvre un popup alimenté par le dernier snapshot du Centre d’opérations; le contenu reste synchronisé pendant le polling silencieux.
- Les erreurs 404 correspondent uniquement aux points réellement sondés par Tech qui retournent HTTP 404; aucune 404 n’est inventée à partir du trafic Stats.
- Les mises à jour importantes regroupent les sites qui remontent des mises à jour WordPress/plugins/thèmes, avec priorité renforcée lorsqu’une mise à jour du core WordPress est disponible.
- Remplace le panneau Incidents à droite de la carte par une vue Temps réel avec Top sites aujourd’hui et liste des sites visités maintenant.
- Le Top sites est classé par pages vues du jour; la liste live est classée par visiteurs actifs puis pages vues.
- Chaque site de la liste live ou du Top ouvre la fiche Tech existante; aucune identité visiteur n’est exposée.
- Incidents résolus, tableau complet du parc, carte GeoIP et courbe transparente restent disponibles sous la vue principale.

# 1.7.2 — carte globale temporelle et graphique fondu

- La carte du Centre d'opérations reprend les périodes : À l'instant, 1 minute, 1 heure, 1 journée, 1 mois, 3 mois et 1 an.
- Tech consomme le nouveau contrat global read-only de Stats AWM 1.8.6; aucune logique GeoIP n'est dupliquée.
- La courbe des visites est maintenant dessinée directement par-dessus la carte avec fond transparent, comme la maquette validée.
- Un changement de période recharge uniquement les données nécessaires; le zoom est recalculé au changement manuel mais reste stable pendant le polling silencieux.
- À l'instant se rafraîchit plus rapidement sans reconstruire Leaflet; les autres périodes conservent un polling silencieux.

# 1.7.1 — clients identifiables sur la carte globale

- Reprend la logique visuelle de carte validée dans Stats AWM : noyau lumineux + halo GeoIP.
- Conserve `client_id + site_id` dans les points de présence Stats afin que le Centre d’opérations sache quel client/site génère chaque activité.
- Regroupe les points qui partagent la même localité et affiche tous les clients/sites concernés dans un popup détaillé.
- Le popup indique client, site, visiteurs actifs et état HTTP sans exposer de données d’un autre contexte hors de la vue Alliance.
- Ajoute le nombre de clients visibles sur la carte et une légende explicite.
- Le premier cadrage automatique n’est effectué qu’une fois; les mises à jour silencieuses ne déplacent plus la carte.
- Aucune nouvelle collecte GeoIP : Stats AWM 1.8.5 reste l’unique source des coordonnées/localités.

# 1.7.0 — Centre d’opérations AWM et incidents de parc
- Remplace le tableau d’ensemble principal par **Vue globale des sites**, un cockpit Alliance qui compile tous les clients et sites connus du registre CRM/Connector.
- Ajoute une sonde HTTP rotative côté Alliance : **12 sites par passage toutes les 2 minutes**, délai maximum de 4 secondes, redirections limitées et validation SSL active.
- Ajoute la base Tech **DB 1.1.0** avec historique des sondes et registre d’incidents; les sondes sont conservées 30 jours et les incidents résolus restent historisés.
- Ouvre un incident HTTP seulement après **deux échecs consécutifs** et un incident de lenteur après deux contrôles consécutifs à **2,5 s ou plus**, afin de réduire les faux positifs.
- Ajoute les incidents `http_unavailable`, `http_slow`, `connector_stale` et `security_alert`, avec résolution automatique lorsque le signal redevient sain.
- Agrège les données réelles Stats AWM disponibles : visiteurs actifs, pages vues du jour, formulaires, trafic horaire, métriques par site et points GeoIP réels sur la carte globale.
- Ajoute une carte Leaflet persistante, une courbe transparente, le classement automatique des sites en anomalie et une actualisation AJAX silencieuse toutes les 30 secondes sans reconstruction complète du dashboard.
- Ajoute un **état opérationnel AWM** (`Normal`, `À surveiller`, `Incident`, `Critique`) calculé à partir des incidents ouverts et un **mode TV** plein écran pour la supervision au bureau.
- Les lignes du parc remontent automatiquement selon la priorité lorsque leur état change; les incidents résolus se mettent aussi à jour sans rechargement complet.
- N’invente aucune donnée : les sites sans première sonde restent `En attente`, et la carte globale n’affiche que les localités GeoIP réellement présentes dans Stats.
- Ajoute **AWM Live Intervention** au futur officiel : le client pourra voir son propre site, le curseur du technicien et les changements appliqués sans voir Tech AWM, wp-admin, Elementor, les logs, prompts ou secrets.

# 1.6.9 — documentation de review publique et continuité roadmap
- Ajoute `ROADMAP.md` au paquet Tech afin que la roadmap publique puisse exposer un contexte de développement complet pour la version effective.
- Aligne README et CHANGELOG sur la version 1.6.9 pour faciliter la review avant tout développement parallèle.
- Aucun changement au runtime, aux Connectors, au `site_id`, à `instance_uuid`, aux secrets, au monitoring ou aux interventions.

# 1.6.8 — heure Alliance explicite et indépendante du fuseau WordPress
- Conserve les événements techniques en UTC mais affiche l administration centrale dans `America/Toronto`, avec changement automatique HNE/HAE.
- Ne dépend plus du fuseau global WordPress pour `Dernier contact` et les horodatages Tech centraux; une installation Alliance restée sur UTC n affiche donc plus quatre heures d avance.
- Réutilise l horloge Core centralisée lorsqu elle est disponible et garde un repli `America/Toronto` autonome dans Tech.
- Aucun changement aux Connectors, secrets, `site_id`, télémétries ou interventions multi-sites.

# 1.6.7 — monitoring Tech réellement par site_id
- Stocke chaque profil Tech dans le registre Connector du site exact (`tech_profile` + `tech_profile_synced_at`) au lieu d écraser les métadonnées globales du client.
- Isole versions WordPress/PHP/Elementor, inventaire, mises à jour, alertes, vulnérabilités et dernier contact pour le site principal, les sous-domaines et les installations en répertoire.
- Les actualisations manuelles et le monitoring de vulnérabilités utilisent désormais `client_id + site_id`; les empreintes critiques ne se mélangent plus entre plusieurs sites du même client.
- Les sessions d intervention sont liées à `client_id + site_id + instance_uuid` et refusent une page située hors du domaine/répertoire canonique du site.
- Le déploiement automatique d un runtime manquant reste limité au site principal tant que le déploiement distant site-scoped n est pas livré, afin d éviter tout déploiement sur le mauvais WordPress.
- La fiche Tech du client et le dashboard distinguent chaque site avec un popup et des actions uniques par `site_id`.

# 1.6.6 — parc client multi-sites
- Consomme `CallLink_CRM::canonical_client_sites()`.
- Liste Site principal et Sites secondaires séparément dans Tech.
- Affiche le rôle, le libellé, l’environnement et la source officielle du design.
- Marque explicitement les secondaires non associés au Connector comme `À connecter`.
- Empêche une intervention distante sur un secondaire non connecté au runtime Tech.
- Prépare l’association future de chaque runtime à un `site_id` précis sans créer de répertoire client parallèle.

# 1.6.5 — monitoring central automatique + inventaire à la demande
- Ajoute un scan central horaire côté Alliance qui réévalue les correspondances de vulnérabilités à partir des inventaires déjà reçus, sans installer de service payant.
- Journalise uniquement les nouvelles correspondances critiques afin de faire ressortir les changements importants sans bruit inutile.
- Ajoute « Actualiser les inventaires » dans le dashboard et la vue Mises à jour : Alliance peut interroger immédiatement les sites via le canal privé Hub Client au lieu d attendre leur prochain contact.
- Affiche la date du dernier scan automatique dans le dashboard et la section Sécurité.
- Conserve Wordfence Intelligence V3 comme source gratuite optionnelle et n ajoute aucune API de vulnérabilités payante.

# 1.6.4 — inventaire versions + journal gratuit des vulnérabilités
- Ajoute un inventaire détaillé WordPress, plugins et thèmes remonté par chaque runtime Tech : version installée, état actif et version de mise à jour proposée.
- Ajoute au dashboard Alliance la comparaison des versions de la Suite AWM avec la publication active.
- Ajoute le journal de vulnérabilités WordPress basé uniquement sur Wordfence Intelligence V3, documenté comme gratuit pour usage personnel et commercial.
- La clé Wordfence gratuite reste chiffrée côté Alliance; elle n est jamais envoyée aux sites clients.
- Compare les versions réellement installées aux plages affectées avant de signaler une vulnérabilité; les niveaux Critique/Élevé influencent le Health Score.
- Met en cache le flux central afin d éviter les appels répétés et n utilise aucune API de vulnérabilités payante.

# 1.6.3 — opacités séparées et choix de police
- Remplace l ancienne opacité totale par deux contrôles indépendants : opacité des fonds (0–100 %) et opacité du texte + bordures (25–100 %).
- Ajoute un choix de police appliqué en direct à toute la fenêtre Tech : Terminal moderne, Consolas, Courier New, Système premium, Arial ou Georgia.
- Conserve couleur terminale, presets Matrix / Bleu premium et réinitialisation; les préférences restent locales au navigateur Alliance.
- Migre automatiquement l ancienne préférence d opacité vers le nouveau réglage de fonds sans rendre le texte illisible.
- N altère ni la session Tech, ni les actions frontend, ni le chargement Elementor.

# 1.6.2 — couleurs fiables, réécriture de contenu et images IA
- Corrige le changement de couleur d un titre : les noms courants comme bleu, vert, or ou rouge sont normalisés vers des valeurs CSS sûres.
- Ajoute un repli CSS frontend limité à la page et réversible lorsque l élément sélectionné n expose pas d ID Elementor utilisable.
- Tech peut maintenant rallonger, condenser, corriger ou rendre plus formel/professionnel le texte sélectionné et proposer le texte complet comme action à appliquer.
- Ajoute une action de génération d image côté Alliance; l image est importée dans la médiathèque WordPress du site client et peut remplacer le widget image Elementor sélectionné.
- Les secrets IA restent chez Alliance; permissions, journalisation, snapshot/hash et rollback restent obligatoires pour les écritures.

# 1.6.1 — moteur d actions frontend
- Tech AWM privilégie maintenant l exécution plutôt que les instructions manuelles : une demande compatible doit produire une action réversible à appliquer.
- Ajoute les réglages design sécurisés pour couleur, taille de police responsive, alignement, marges, padding et fonds Elementor.
- Enrichit la sélection frontend avec les styles calculés de l élément ciblé afin de donner un contexte visuel concret à l IA.
- Affiche le plan d actions exact dans la fenêtre Tech avant « Appliquer maintenant ».
- Conserve snapshot, contrôle de hash Elementor, permissions Alliance, journalisation et rollback avant toute écriture.

# 1.6.0 — Dashboard Tech opérationnel + intervention frontend directe

- Fait du frontend du site client la surface d intervention principale; Elementor reste un mode avance distinct.
- Ajoute une session frontend Alliance temporaire qui conserve la fenêtre Tech pendant la navigation du site, sans exposer Tech aux visiteurs ordinaires.
- Ajoute la sélection visuelle directe des éléments Elementor depuis le frontend et conserve snapshot / appliquer / rollback côté serveur.
- Refonte le tableau de bord principal avec KPI réels, score de santé dérivé, priorités, sites surveillés et activité récente.
- Chaque carte, priorité et ligne du dashboard est cliquable et ouvre sa source dans une popup contextuelle; la navigation principale reste dans le menu WordPress à gauche.
- Ajoute les entrées WordPress : Tableau de bord, Sites, Monitoring, Alertes, Mises à jour, Sauvegardes, Sécurité, Rapports, Journal et Réglages.
- N invente aucune donnée de monitoring : les métriques absentes (sauvegardes, uptime historique, temps de réponse) restent explicitement marquées comme sondes à brancher.

# 1.5.18 — fenêtre persistante WordPress + Elementor et personnalisation

- Maintient la boîte Tech active pendant la navigation dans l administration WordPress tant que la session Alliance temporaire reste valide.
- Conserve la même session et la même page cible lors des passages WordPress ↔ Elementor; la sélection visuelle demeure réservée à Elementor.
- Ajoute un panneau Apparence dans la boîte : couleur terminale, code hexadécimal, opacité totale 25–100 %, presets Matrix / Bleu premium et réinitialisation.
- Les préférences sont appliquées en direct et conservées localement dans le navigateur du technicien, sans donnée client supplémentaire.
- Tech reste absent du Hub Client et du front-end public.

# 1.5.17 — isolation du preview Elementor et suppression de la boucle Safe Mode

- Corrige la cause du blocage **Loading / Enable Safe Mode** observé pendant une intervention Tech : le cookie de session Alliance était aussi lu dans l iframe `elementor-preview`.
- L iframe de prévisualisation Elementor est maintenant explicitement exclue du bootstrap front-end Tech avant toute validation, redirection ou création de handoff.
- Une session Tech conservée en cookie ne peut plus rediriger une page publique ordinaire vers `wp-admin`; seule une URL de lancement Tech explicite peut déclencher le parcours legacy.
- Le mode `editor_only` ne provoque plus de redirection à lui seul sur les requêtes front-end.
- Conserve la boîte terminal Matrix, le handoff serveur direct et les routes REST privées sans toucher au fonctionnement normal de la prévisualisation Elementor.

# 1.5.16 — Elementor Safe Boot + terminal Matrix

- Retarde complètement l initialisation JavaScript de la boîte Tech jusqu à ce qu Elementor ait réellement créé son interface et sa prévisualisation.
- Retire le MutationObserver global pendant le bootstrap Elementor et utilise un polling borné beaucoup plus léger.
- Empêche le double enqueue/localize lorsque les hooks WordPress et Elementor se déclenchent dans la même requête.
- N injecte plus le HTML de la boîte dans le footer avant que l éditeur soit prêt; la boîte est créée côté navigateur seulement après l initialisation Elementor.
- Nettoie le CSS terminal Matrix et applique une vraie police console, texte vert, fond noir/vert et accents lumineux à la boîte Tech.
- Si Elementor ne devient pas prêt dans les 30 secondes, Tech reste passif au lieu d ajouter de la charge au démarrage.

# 1.5.15 — Lancement Elementor fiable et visible

- Corrige le cas où un clic sur **Elementor** semblait ne rien faire pendant la préparation distante.
- Le clic affiche immédiatement un écran compact de progression avant l'appel serveur.
- Le POST vers `admin-post.php` est déclenché explicitement après le premier rendu visuel afin d'éviter qu'un script tiers neutralise le bouton.
- La préparation reste côté serveur, avec validation Hub Client / Tech, session Alliance signée et redirection uniquement vers le domaine jumelé.
- Aucun changement n'est apporté au chargement non intrusif de la boîte Tech dans Elementor introduit en 1.5.14.

# 1.5.14 — Terminal Matrix et chargement Elementor non intrusif

- Retire l injection directe des assets Tech dans `admin_head`, trop précoce pour certaines versions d Elementor et susceptible de perturber son démarrage.
- Les assets de la boîte Tech passent désormais uniquement par les files d enqueue et hooks de l éditeur Elementor, avec rendu de la boîte en fin d interface.
- Conserve une seule boîte de dialogue et aucun composant Tech sur le front public.
- Applique une esthétique terminale monospace vert Matrix à la saisie, aux messages et au diagnostic.
- Conserve le handoff Hub Client sécurisé et la session Alliance temporaire.

# 1.5.13 — handoff Hub Client et préflight live

- Tech central relit `update/status` juste avant une intervention afin de ne plus redéployer à cause d une télémétrie CRM périmée.
- Le préflight exige Hub Client 1.11.29+, Tech 1.5.13+ et la route privée de préparation réellement disponible.
- Dans Elementor, Tech accepte le handoff autonome créé par Hub Client et revalide silencieusement la session auprès d Alliance dans la nouvelle requête.
- Si la revalidation réseau échoue momentanément, la session déjà validée par Hub Client reste utilisable jusqu à son expiration.

# 1.5.12 — boot client resilient et contrat Hub Client

- Tech client se relance de facon idempotente sur `plugins_loaded`, `init` et `rest_api_init` afin de survivre aux remplacements a chaud du plugin.
- Le mode client depend maintenant de la presence de Hub Client, sans exiger qu une classe auxiliaire soit deja visible au moment exact du premier test.
- La route privee de preparation Elementor est desormais possedee par Hub Client 1.11.26; Tech conserve la logique de validation, resolution de page et creation du handoff.
- Le preflight Alliance exige Hub Client 1.11.26 ou plus recent.

# 1.5.11 — ouverture Elementor par handoff serveur direct

- Remplace le passage fragile front-end → `wp-admin` par une préparation serveur-à-serveur entre Core Alliance et l agent Hub Client du site.
- Le site résout la page cible, valide la session Alliance et retourne une URL Elementor contenant uniquement un handoff local à usage unique.
- Le handoff est consommé dans `admin_init`, puis supprimé; la boîte Tech est injectée dans `admin_head` avant le démarrage de l éditeur.
- Ajoute une route privée `awm-client-hub/v1/tech/intervention/prepare`, protégée par le secret de scan du site et la validation Connector de la session.
- Exige Hub Client 1.11.25 pour invalider OPcache après les mises à jour distantes et confirmer la version Tech réellement chargée, pas seulement la version du fichier.
- Si le runtime Tech ou le handoff ne sont pas réellement actifs, l ouverture Elementor s arrête avec une erreur explicite au lieu d ouvrir silencieusement sans boîte.

# 1.5.10 — continuité de session Elementor renforcée

- Corrige le transfert de session Tech entre le front du site et `wp-admin` lorsque le domaine bascule entre `www` et le domaine nu.
- Ajoute un handoff serveur temporaire et un cookie de domaine sécurisé pour restaurer la session dans Elementor même si les paramètres d URL sont retirés.
- Injecte les assets de la boîte Tech directement dans `admin_head` pendant une session valide, sans dépendre du footer Elementor ou de la file d enqueue WordPress.
- Affiche un diagnostic Tech explicite dans Elementor si une intervention a été demandée mais que la session ne peut pas être récupérée.
- Corrige les appels Connector d intervention pour transmettre le timeout avec la bonne signature.
- La boîte reste unique et réservée à Alliance; aucune surface Tech n est exposée au client.

# 1.5.9 — boîte Elementor injectée par les hooks natifs
- Corrige l absence de boîte Tech dans certaines versions récentes d Elementor : le runtime utilise maintenant les hooks officiels `elementor/editor/after_enqueue_scripts`, `elementor/editor/after_enqueue_styles` et `elementor/editor/footer`.
- Conserve `admin_enqueue_scripts` et `admin_footer` uniquement comme repli de compatibilité.
- Ajoute une deuxième sécurité côté JavaScript : si Elementor ne rend pas le HTML du footer attendu, la boîte unique est reconstruite depuis le markup de session localisé.
- Empêche les doublons lorsque le hook Elementor et le hook WordPress sont tous les deux exécutés.
- Tech reste invisible hors d une session Alliance valide et aucune palette n est ajoutée au front-end public.

# 1.5.8 — préparation Elementor automatique

- Le bouton d intervention ne bloque plus lorsque le site client possède une version Tech plus ancienne.
- Tech AWM utilise la publication active de Core pour installer ou mettre à jour automatiquement le runtime Tech requis avant d ouvrir Elementor.
- La version distante est relue et confirmée avant de créer la session d intervention.
- La liste Sites affiche `Préparer + Elementor` lorsqu une mise à jour Tech est requise, puis ouvre directement Elementor après préparation.
- Les erreurs de préparation remontent avec un message explicite au lieu du blocage générique `Tech X requis`.
- Tech reste invisible pour le client; seule la boîte de dialogue privée Alliance existe dans Elementor.

# 1.5.7 — Heure de dernier contact corrigée
- Corrige l heure affichée dans **Tech AWM → Sites** : le contact Tech est stocké en UTC mais est maintenant converti dans le fuseau horaire WordPress d Alliance avant affichage.
- Évite le décalage de quatre heures observé lorsque l administration Alliance utilise `America/Toronto` pendant l heure avancée.
- Conserve la valeur brute UTC en stockage afin de garder une télémétrie cohérente entre les sites.
- Ajoute le fuseau horaire Alliance en infobulle sur la colonne **Dernier contact**.
- Applique la même conversion au dernier succès Connector reçu par la télémétrie Tech lorsqu il est stocké au format UTC.

# 1.5.6 — Stabilisation de l intervention Elementor
- Ajoute un préflight côté Alliance : le bouton Elementor n est disponible que si Tech AWM 1.5.6 et Elementor sont confirmés sur le site client.
- Affiche dans l unique boîte Tech l état de connexion et le temps restant de la session privée Alliance.
- Attend automatiquement le chargement de l iframe Elementor avant le mode Sélectionner au lieu d obliger le technicien à réessayer manuellement.
- Réinitialise proprement une sélection devenue obsolète lorsque l aperçu Elementor est rechargé.
- Après Appliquer ou Rollback, recharge l aperçu Elementor sans recharger toute l interface WordPress lorsque l API Elementor le permet.
- Durcit le JavaScript de la boîte Tech pour qu un contrôle absent ne bloque plus toute l intervention.
- Conserve une seule boîte de dialogue Tech et aucune surface sur le front-end public.

# 1.5.5 — Intervention Elementor directe avec une seule boîte de dialogue
- Le bouton d intervention Alliance ouvre désormais directement la page cible dans l éditeur Elementor.
- Supprime la palette Tech du front-end public : aucune surface d intervention n y est rendue.
- Dans Elementor, affiche une seule boîte de dialogue Tech AWM, compacte, déplaçable et réductible.
- La boîte regroupe conversation, sélection d élément, pièces jointes, application, diagnostic et rollback sans ajouter de deuxième palette.
- La session reste temporaire, liée au client, au domaine et à la page, et Tech demeure invisible au client.

# 1.5.4 — Liste des sites visible directement dans Vue d’ensemble
- Affiche la liste d’intervention des sites Hub Client directement sous le tableau de bord Tech AWM, sans devoir cliquer sur un simple lien.
- Conserve l’onglet **Sites** dédié pour la vue complète.
- La liste reste alimentée par CRM canonique + inventaire Core, avec actions **Intervenir**, **Fiche Tech** et **Voir**.
- Corrige le doublon du champ de recherche dans la vue Sites.

# 1.5.3 — Palette Tech dans l’éditeur Elementor
- Corrige la session d’intervention Tech lorsqu’une page est ouverte avec `action=elementor` dans wp-admin.
- La palette privée Alliance est maintenant injectée directement dans l’interface de l’éditeur Elementor et s’ouvre automatiquement pendant une session Tech valide.
- La session reste liée au client, au domaine, à la page et au navigateur via le jeton temporaire; aucune palette n’apparaît sans intervention Alliance active.
- Le mode **Inspecter** cible maintenant le document de prévisualisation Elementor dans son iframe et permet de sélectionner un élément directement depuis l’éditeur.
- Empêche l’affichage d’une deuxième palette dans l’iframe `elementor-preview` afin de garder une seule boîte de dialogue visible.
- Conserve Tech totalement invisible dans le Hub Client et pour les visiteurs.

# 1.5.2 — Section Sites visible et accès direct
- Corrige la navigation Alliance : la section **Sites** est maintenant exposée directement dans le shell Tech AWM.
- Le menu Tech AWM ouvre désormais la liste des sites Hub Client par défaut pour accélérer les interventions.
- La vue d’ensemble reste disponible comme onglet séparé.
- La liste continue d’utiliser uniquement les fiches CRM canoniques et les sites où Hub Client est confirmé installé.
- Tech demeure totalement invisible dans Hub Client et réservé à Alliance Web Marketing.

# 1.5.1 — Liste des sites Hub Client et intervention directe
- Ajoute dans Tech AWM une liste centrale de tous les sites où Hub Client est confirmé installé.
- Réutilise le client_id CRM canonique, le Connector et l’inventaire Core sans créer de répertoire client parallèle.
- Affiche version Hub Client, état/version Tech, mises à jour, alertes, transport Connector et dernier contact.
- Permet de lancer une intervention Tech directement depuis la ligne du site lorsque l’agent est installé et autorisé.
- Conserve un accès à la fiche Tech complète pour activation, permissions, URL cible précise et diagnostic.
- Les sites sans Hub Client confirmé ne sont jamais proposés comme cibles d’intervention.

# 1.5.0 — Centre Tech privé et intervention front-end Alliance

- Tech AWM n est plus un service client : son interface est exclusivement réservée à Alliance Web Marketing.
- Ajoute des sessions d intervention front-end temporaires (20 min), liées au client, au domaine et à la page ciblée.
- La palette Tech est injectée uniquement lorsqu une session Alliance valide est ouverte; elle est invisible aux visiteurs et au Hub Client.
- Ajoute inspection Elementor, diagnostic, design, réparations ciblées, application contrôlée et rollback dans la session privée.
- Ajoute un scan horaire de santé/sécurité : mises à jour disponibles, changements sensibles de baseline, échecs de connexion inhabituels et événements de mise à jour.
- Toutes les interventions sont auditées côté Alliance sans journaliser le jeton de session.

## 1.4.3 — 2026-09-05
- Ajoute un centre de santé Tech AWM dans Hub Client : versions, dernier contact, transport Connector et journal technique récent.
- Ajoute les actions Diagnostic complet, Tester la liaison, Réparer la connexion, Resynchroniser Alliance et Vider les caches AWM.
- Teste séparément REST avec en-têtes, REST avec secret dans le corps HTTPS, admin-ajax et pont frontal, sans journaliser le secret Connector.
- Les actions de réparation exigent un administrateur WordPress et respectent la permission centrale `wordpress_safe_actions`.
- Transmet à Alliance le dernier transport, le dernier succès Connector et le dernier événement Tech via le profil sécurisé existant.

## 1.4.2 — 2026-09-04
- Le runtime Tech utilise le transport Connector résilient de Hub Client pour statut, chat et résultats d'actions.
- Aucun secret supplémentaire ni base client parallèle.

## 1.4.1 — 2026-09-04

- Corrige la vérification d'autorisation Tech entre Hub Client et Alliance sur les hébergements qui filtrent les en-têtes HTTP personnalisés.
- Les appels Tech utilisent le transport Connector HTTPS compatible par corps chiffré en transit, sans exposer le secret dans le navigateur.
- Le statut Tech retourne le `client_id` CRM canonique afin que Hub Client puisse confirmer/réparer son rattachement local.

## 1.4.0 — 2026-09-04
- Corrige le menu principal Thech AWM : il ouvre maintenant son propre tableau de bord au lieu de rediriger automatiquement vers CRM.
- Ajoute une vue d ensemble Tech autonome; seul l onglet Clients ouvre explicitement la recherche CRM canonique.
- Ajoute la fenêtre Tech AWM flottante directement sur le front-end des pages WordPress/Elementor autorisées.
- La fenêtre connaît automatiquement la page courante, son post_id et son contexte Elementor.
- Le mode Inspecter permet de cibler un élément Elementor directement dans la page.
- Corrige les conversations multi-tours OpenAI : les anciens messages assistant sont transmis en output_text et les messages utilisateur en input_text.
- Depuis Hub Client, une URL interne est résolue vers la page WordPress réelle et devient la cible des actions Appliquer / rollback.
- Affiche la page cible dans la conversation pour éviter toute modification ambiguë.

## 1.3.0 — 2026-09-04
- Thech/Tech AWM utilise exclusivement le `client_id` canonique de CRM AWM.
- Le moteur de recherche Clients de Thech ouvre la liste et la fiche client CRM.
- L onglet Tech est injecté dans la fiche client CRM unifiée.
- Activation, permissions, mémoire, diagnostics, consommation et journal restent des données Tech liées au même `client_id`, sans copie de la fiche client.

## 1.2.0 — 2026-09-04
- Remplace la grande table Sites et autorisations par le parcours client canonique du Hub.
- L onglet principal Clients de Thech AWM ouvre désormais le moteur de recherche habituel des fiches clients.
- Ajoute un onglet Tech directement dans chaque fiche client Hub AWM.
- Déplace activation, permissions Chat / Diagnostics / Elementor / WordPress / Fichiers et état du runtime dans cet onglet Tech.
- Conserve l activation exclusivement côté Alliance et journalise les changements de permissions.
- Préserve le contexte Thech AWM dans le shell Premium lorsque la fiche est ouverte depuis Tech.

# Changelog Tech AWM

## 1.1.0 — 2026-09-04
- Devient un paquet physique autonome dans la Suite AWM.
- Regroupe le module central Thech AWM et le runtime client Tech AWM.
- Conserve l'activation exclusivement contrôlée depuis Alliance.
- Réutilise Hub Client et son moteur Elementor sécurisé sans dupliquer les données métier.
- Préserve le shell Premium, la mémoire centralisée, le suivi des tokens, les pièces jointes et le rollback.