Appearance

Registre des defauts mesures - phase 1 de migration-completion-plan.md ​

Un seul registre pour les trois marques. Chaque entree porte SA MESURE : sans un nombre releve sur le live, une ligne d'ici n'est pas un defaut, c'est une impression. Les entrees sans mesure sont marquees A MESURER et ne doivent PAS etre corrigees en l'etat.

Classement : systemique (une correction partagee deplace plusieurs pages) avant par page. Ouvert le 2026-07-30.

Etat de la phase 1 ​

voletoutiletat
Contenu PDN : seed vs export WordPresstools/seed-gen/pdn-content-audit.mjsFAIT (2026-07-30)
Visuel + interaction, PDN 20 pages x 5 largeurssweep.mjs, probes/*, interact.mjsa faire
Visuel + interaction, gilliard 22 pagesidema faire
Visuel + interaction, chevaliers 12 pagesidema faire

A. Contenu PDN - mesure du 2026-07-30 ​

Source : node tools/seed-gen/pdn-content-audit.mjs (relancer apres tout re-seed). Export : tools/portedenovembre.WordPress.2026-07-30.xml -> data/sources/pdn/ via node tools/seed-gen/wxr-extract.mjs pdn.

A1. Couverture - PROPRE, rien a faire ​

28 pages seedees, 28 appariees a l'export. Aucune page manquante, aucune page en trop. Les deux seuls items de l'export absents du seed sont un brouillon (Gallery Party, sans slug) et un article prive (snow-vibes-11-et-12-avril-a-nendaz) : les seeder AJOUTERAIT du contenu que le live ne montre pas, donc leur absence est correcte.

A2. Media - PROPRE, rien a faire ​

0 orphelin. Les 314 images de bibliotheque utilisees par le seed sont toutes dans l'export (une fois repliees les variantes de taille -WxH et -scaled). Les 14 restantes sont generees et ne seront jamais des pieces jointes : le cache Smash Balloon (sb-instagram-feed-images, bande masquee de toute facon) et les recadrages Elementor (elementor/thumbs).

A3. ⚠️ SYSTEMIQUE - les 7 pages de detail de vin sont AMPUTEES de 25 a 33 % du texte ​

C'est le defaut de contenu le plus net de PDN, et il ne touche QUE ces 7 pages.

pagemots chez nousmots dans l'exportdelta
vins/johannisberg-pdn97145-48
vins/rose-pdn82124-42
vins/rouge-pdn75112-37
vins/ice-rose-pdn96131-35
vins/ice-0-085119-34
vins/ice-pdn94127-33
vins/mousseux73102-29

Toutes les autres pages sont a +-4 % (accueil +36 sur 302, vins -4, idees-cadeaux et goodies a l'identique, contact -1, confidentialite +42 sur 1659, les 10 articles entre -19 et +1).

Cause TROUVEE et VERIFIEE CONTRE LE LIVE (2026-07-30) - le commit 9b4157e est une regression ​

Le texte manquant est exactement la section « Détails ». Pour johannisberg-pdn, l'export porte 7 paires fait/valeur que nous ne rendons pas du tout :

libellevaleur
CépageJohannisberg
AppellationAOC Valais
NezFruit du raisin bien mûr, poire, noisette et amande
BoucheMoelleux, puissant, légère amertume finale en fin de bouche
Analyse12% vol. alcool, contient des sulfites
Idéal avecApéritif, poissons en sauce, crustacés, asperges, fromages à pâte dure
Garde4 ans

Notre build ne rend que le titre « Détails », suivi de rien.

**Le commit 9b4157e a saute ces faits quand parent === "vins", sur la base d'une mesure affirmant que « la section Détails du live est VIDE - les icon-box sont dans le DOM mais ne sont pas rendues ». Cette mesure etait FAUSSE. Re-mesure du 2026-07-30 sur https://portedenovembre.ch/vins/johannisberg-pdn/ @1440, les 10 elements testes :

Détails      -> 1270x35 @y912   display:block  vis:visible op:1  PAINTS:YES
Cépage       -> 80x23   @y1026  display:inline vis:visible op:1  PAINTS:YES
Appellation  -> 121x23  @y1119  ...                              PAINTS:YES
AOC Valais   -> 521x31  @y1146  ...                              PAINTS:YES
Nez / Bouche / Analyse / Idéal avec / Garde / 4 ans              PAINTS:YES

Capture d'ecran a l'appui : une grille DEUX COLONNES de tuiles roses (icone + libelle en gras + valeur), pleinement peinte. C'est l'inverse du piege habituel : au lieu de porter une bande que le live ne montre pas, nous avons SUPPRIME une bande que le live montre.

✅ CORRIGE le 2026-08-01. Nouvel element factsPanel (titre + Core - Facts), branche dans la grille PDNContentBlocks, avec son partial et ses styles. factItem et Core - Facts existaient depuis le debut et ne servaient a rien : ils servent maintenant. Les 7 icones ont ete extraites du DOM du live (elles y sont en SVG inline, pas servies comme fichiers), deposees dans wwwroot/images/pdn/facts/ et importees comme MEDIA - donc l'icone d'un fait reste un choix d'editeur, pas une chaine dans une feuille de style. La ligne du generateur qui supprimait la bande (if (parent === "vins" && spec.block === "facts") continue;) emet desormais un factsPanel.

Verifie contre le live @1440, chaque nombre identique : lignes 615x73 (et 615x92 quand la valeur passe a deux lignes) aux x85 et x740, icone 73x73, texte a +94 (x179 / x834), libelle et valeur 20.4px/30.6px en w700 / w400, gouttiere 21px, pas de 93 / 111. Bande capturee et relue : indiscernable du live.

⚠️ Une deviation mesuree, sur ice-0-0 uniquement. Le live y masque 3 de ses 7 widgets, mais ses colonnes restent celles des 7 : la colonne 1 garde les widgets 1-4 (dont un masque) et la colonne 2 les 5-7 (dont deux masques), ce qui donne 3+1. Notre panneau ne connait que les 4 faits visibles et les repartit en ceil(n/2) = 2+2. Les 6 autres pages ont 7 faits et tombent donc sur le 4+3 du live. Corriger le cas restant demanderait de porter le point de rupture en donnee ; note ici plutot que devine.

⚠️ Non porte : la decoration raisins.png que le live pose en fond du second conteneur (spec §B4).

La correction rejoint la phase 2.2. La forme du live - icone + libelle + valeur - est exactement ce que factItem (label / value / icon) et le DataType Core - Facts decrivent, tous deux construits et cables a rien. Le factsPanel n'est donc pas seulement une amelioration d'experience editeur : c'est le mecanisme qui repare ce defaut visuel sur 7 pages. ⚠️ Sur PDN, « Détails » est une BANDE dans le flux de la page, pas un panneau lateral - il lui faut donc un bloc dans la grille pdnCanvas, pas seulement une composition. Les 7 icones (grappe, ecusson, nez, bouteille, verre, caisse) sont des medias a importer.

Specification mesuree de la bande (live, 5 largeurs, 2026-07-30) ​

375768102414401920
titre « Détails »35px Yeseva One noir - constant a toutes les largeursidemidemidemidem
ligne (.elementor-icon-box-wrapper)315x73324x73452x73615x73615x73
iconeSVG 73x73 (fond transparent sur le <svg> : la tuile rose vient de son conteneur)idemidemidemidem
libelle16px/24.48 w70017px/26.86 w70017px/25.5 w70020.4px/30.6 w700idem
valeur16px/24.48 w40017px/26.86 w40017px/25.5 w40020.4px/30.6 w400idem
texte a gauche de l'icone+94px du bord de l'icone (73 + 21 de gouttiere) - constantidemidemidemidem

Libelle et valeur partagent taille et interlignage ; seule la graisse les distingue (700 / 400), tous deux en noir. Le decalage de 94px est constant : c'est une gouttiere fixe de 21px, pas un pourcentage. Le nombre de colonnes reste A MESURER - la detection automatique a ramasse des SVG decoratifs de la page ; la capture a 1440 en montre deux, a confirmer aux autres largeurs.

A4. Noms de noeuds - 19 des 28 noeuds portent un slug, pas un titre ​

Defaut d'experience editeur : dans l'arbre du backoffice, un editeur lit ice-0-0 au lieu de « Ice 0.0% ». Le nom du noeud pilote aussi l'URL - un simple renommage deplace la page (essaye et annule le 2026-07-23 : « Nos vins » avait deplace les 6 pages de vin de /vins/<slug>/ vers /nos-vins/<slug>/). Le renommage exige donc umbracoUrlName fixe sur le slug du live dans le meme changement.

nom du noeud aujourd'huivrai titreslug du live a figer
AccueilPorte de Novembrenight-bar
ÉvénementsEventsevenements
VinsNos vinsvins
johannisberg-pdnJohannisbergjohannisberg-pdn
rose-pdnRosérose-pdn
rouge-pdnRougerouge-pdn
ice-rose-pdnIce Roséice-rose-pdn
ice-pdnIceice-pdn
ice-0-0Ice 0.0%ice-0-0
pink-watermelonPink Watermelonpink-watermelon
ice-ice-babyIce Ice Babyice-ice-baby
sangria-pdnSangria PDNsangria-pdn
cucumber-novemberCucumber Novembercucumber-november
sortie-du-ice-roseSortie du ICE Rosésortie-du-ice-rose
nouveau-mousseuxNOUVEAU - Mousseux Porte de Novembrenouveau-mousseux
novembre-toute-lanneeNOVEMBRE toute l'annéenovembre-toute-lannee
new-porte-de-novembre-ice-0-0NEW - Porte de Novembre ICE 0.0%new-porte-de-novembre-ice-0-0
activite-decouvrir-la-porte-de-novembreActivité : DÉCOUVRIR LA PORTE DE NOVEMBREactivite-decouvrir-la-porte-de-novembre
gilliarday-festival-du-28-au-31-juillet-a-sionGILLIARDAY FESTIVAL, du 28 au 31 juillet à Siongilliarday-festival-du-28-au-31-juillet-a-sion

⚠️ Accueil est la RACINE de la marque : son nom apparait dans le backoffice mais pas dans l'URL. Le renommer en « Porte de Novembre » est sans risque d'URL, mais verifier les seeders qui resolvent des noeuds par nom.

A5. Extraits - contrainte reelle, pas un oubli ​

Seuls 4 des 30 items FR ont un excerpt:encoded rempli : les 4 articles cocktails (cucumber-november, ice-ice-baby, pink-watermelon, sangria-pdn). Les 26 autres n'en ont aucun. La carte de listing du live affiche pourtant un extrait : il est donc derive du corps pour tout le reste. C'est une contrainte de conception de la carte de listing PDN (phase 5, item 2), pas un manque de donnees a combler.

A6. Balisage Elementor - 24 items sur 28 ​

24 items seedes portent du .elementor-* dans post.html. La regle permanente est de porter le resultat rendu, jamais le plugin. SeedHtml.Clean() (dans DevSeedSupport.Rich()) est le point de passage unique de tout corps RTE seede, et sa garantie est que le nombre d'elements ne peut jamais changer - donc l'aplatissement doit se faire dans le generateur, en amont.

B. Visuel + interaction ​

⚠️ STATUT DE VERIFICATION. Les sections marquees [AGENT] viennent d'agents de mesure en lecture seule (2026-07-30). Ils portent des nombres, pas des impressions - mais l'historique de ce projet dit qu'environ la moitie des trouvailles d'agent sont fausses. Rien ici n'a encore ete re-verifie par la session principale. Verifier chaque candidat contre le live AVANT et APRES correction. Les entrees [MESURE] ont ete relevees directement par la session principale.

B0. Deux notes permanentes qui etaient PERIMEES - corrigees par la mesure ​

  1. Le souligne de navigation « centre vers l'exterieur » n'existe plus dans le code. ⚠️ CETTE NOTE EST FAUSSE - VOIR §C1. Elle avait raison sur notre cote (notre CSS EST left-origin, ::before { left:0; width:0 }) et tort sur le live : la regle du live est left:0; right:0; margin:auto, donc le live est centre-out. La note de cont.19 avait donc le probleme a l'envers. Mesure de premiere main + regle CSS relevee en §C1, avec les quatre defauts reels (origine, largeur, easing, declencheur li:hover).
  2. Les icones sociales du pied de page ne sont PAS des SVG inline dans un cercle. gilliard et chevaliers rendent deja un PNG 24x24 en background-image, background-size:contain, sans cercle - conforme au live. La note etait perimee. En revanche PDN n'affiche AUCUNE icone (background-image: none) : ca, c'est un vrai bug (B1-4).

B1. [AGENT] Chrome partage et etats d'interaction - 18 defauts ​

La colonne « portee » est le piege principal : corriger dans base/ ce qui est propre a une marque regresse les autres. Elle est indiquee pour chaque ligne.

#composantmarqueslivelocalportee
1anneau de focus des champsles 3outline:1px auto rgb(16,16,16), box-shadow:none (anneau UA)outline:3px none + box-shadow accent 0 0 0 1pxbase
2champ du formulaire contactpdn308x51, sans bordure, fond transparent, pad 13px 0 13px 36px, 2 champs par ligne873x53, bordure 1px rgba(0,0,0,.12), fond blanc, pad 10px 15px, 1 par lignetheme pdn
3lien + intitule du piedpdnlien blanc -> survol rgb(255,204,102)lien rgb(252,141,163), survol inchangetheme pdn
4glyphe social du piedpdnglyphe present.site-footer__social-ico 24x24 background-image:none - rien ne peinttheme pdn
5champ newslettergilliard280x50, bordure + texte + placeholder OR rgb(142,120,76), pad 12px 15px268x52, bordure + texte NOIRS, pad 0 16pxtheme gilliard (base est juste pour chevaliers - ne pas deplacer)
6bouton newslettergilliard + chevaliersgilliard 48x50 sans bordure ; chevaliers 46x56 bordure noireles deux 52x52, bordure rgba(0,0,0,.2)base (la boite) + par marque (la bordure)
7grille de colonnes du piedgilliard + chevaliersx = 278 / 728 / 1066295 / 740 / 1084 (decalage identique +17/+12/+18)base
8inventaire des liens du piedgilliard + chevaliers15 / 13 liens visibles14 / 12base (pilote par le contenu - identifier la ligne manquante)
9metriques d'intitule du piedgilliardH4, interligne 24px, marge basse 21.28pxH3, interligne 19.2pxbase (~5px par colonne)
10hauteur de la bande piedchevaliers1440x4401440x392 (-48px @1440)base (cumul de 7/9 + barre legale 54 vs 58)
11largeur ET ORIGINE du souligne navles 3largeur du TEXTE (38.56 / 43.53 / 74.53 ; gilliard « Contact » 46.63), et centre (left:0;right:0;margin:auto)calc(100% - 15px) = 61.59 / 72.08 / 88.27, ancre a gauchebase - CONFIRME par la session principale, §C1. Trop large ET decale de ~23px
12geometrie du souligne navpdn::after, 2px, blanc, bottom:-2px (SOUS le lien)::before, 1px, bottom:10px (dedans, ~12px trop haut)theme pdn
13easing du souligne navgilliard + chevaliersall 0.2s ease-in-out, declenche par li:hoverwidth 0.2s (donc ease), declenche par a:hoverbase - CONFIRME, §C1
14icones utilitaires d'en-tetegilliard + chevaliers<img> 35x35 @y35 ; gilliard account.svg + cart2.webp<svg> inline 28x28 @y41 ; gilliard trace en rgb(168,143,105) et non l'or de marque ; panier chevaliers a +32pxbase (28->35) + par marque (l'art et sa couleur)
15selecteur de languepdna.sf-with-ul 51x50 @1309, 16px w700, porte un sous-menupilule plate 26x36 @1379theme + gabarit pdn
16panneau deroulantpdn204x302 @413,112, fond blanc OPAQUE, pad 12px 0, items h40 pad 10.4/25.6 noirs, ancre +18px sous l'item, fadeIn250x224 @394,91, rgba(255,255,255,.98), pad 0, items h32 4/15 rgb(50,50,50), recouvrement 0, sans entreetheme pdn (tout le spec gilliard lui est applique)
17typo du tiroir mobile @375gilliardniveau 1 13.125px / ls 1.3125 / pad 7px ; enfants 15pxniveau 1 20px / ls 2px / pad 13.6/4 / h52 + filet ; enfants 20pxbase (taille exacte par marque ; UNVERIFIED sur chevaliers/pdn - le tiroir local n'a pas pu etre ouvert)
18transition + padding des boutonsles 3transition: .3s ease-in-out (toutes proprietes), pad 10px 20pxtransition Bootstrap .15s sur 4 proprietes, pad 10px 21.6px (gilliard)base (la DESTINATION du survol est correcte - seuls le timing et la boite different)

UNVERIFIED signales par l'agent, a re-mesurer avant toute action : panneau deroulant chevaliers (le survol reel n'a pas ouvert le panneau) ; ombre au survol des hero-box gilliard (resultats contradictoires entre marques sur un CSS live identique) ; nombre d'items du deroulant gilliard (+1 ligne chez nous, le live masque Voir tous nos vins a h0) ; couleur du <a> des cartes (rgb(50,50,50) live vs rgb(155,155,155) local, mais le titre peint n'a pas ete mesure) ; CTA du hero chevaliers (rgb(12,79,41) live vs or gilliard qui fuit dans le theme chevaliers - dans la region masquee, donc hors classement mais a corriger quand meme).

B2. [AGENT] Accueil PDN - 15 defauts ​

Les trois items signales par l'utilisateur sont RESOLUS en mesure (plus d'hypothese) :

  • Echelle de la bouteille du hero. Live : SHARE 686x369 @1440, 860x452 @1920, 487x262 @1024, 363x195 @768 - soit ~47,6vw @1440 / 44,8vw @1920. Local : bloque a 593x312 a 1440 ET a 1920 (une largeur plafonnee au lieu d'une echelle). Par slide : Enjoy live 506x471@1440 / 610x567@1920 contre local 507x471 / 593x551 ; Cheers live 450x544 / 433x523 contre local 390x471 / 513x620 - local trop petit a 1440 et trop grand a 1920. C'est ce qu'il fallait pour reconcilier slide par slide sans casser Enjoy/Cheers.
  • Survol de la grille « Découvrez nos vins » - le BON element est enfin identifie : .elementor-element-6b43e64 .elementor-widget img.elementor-animation-float (l'ancienne sonde visait .sc_blogger_item, un teaser d'article). Live : repos transform:none -> survol translateY(-8px), transition: transform .3s ease-out ; la couleur du lien passe aussi de rgb(198,153,251) a rgb(187,133,250). Local : a.g-card, .g-card__media et .g-card__linkne changent RIEN au survol force. Le soulevement est entierement absent.
  • Transition de slide. Live = fondu enchaine SUR PLACE : l'image sortante passe de l'opacite 1 a 0 en ~200 ms, la couche entrante de 0 a 1 avec un translateY de -36.97px @1440 / -50px @1920 / -11px @375 vers 0 sur ~700 ms apres ~250 ms de delai ; les slides ne se deplacent jamais horizontalement. Local = un Swiper horizontal ordinaire (translateX(0 -> -1440px) sur 0.7s), toutes les couches restant a opacity:1, transform:none, animation:none. Ce n'est pas un reglage a ajuster, c'est un autre mecanisme.

Autres defauts de l'accueil :

#elementlivelocalnote
1bande 2, mise en page798x418, 2 colonnes cote a cote @768768x854, 1 colonne, media SOUS le texteexplique a lui seul les +333px de hauteur a 768
2hero, empilement mobileimage 301x162 @36,281 PUIS bouton 173x48 @101,491bouton AU-DESSUS, image 159x83 collee en basimage a 47 % de la largeur du live, 261px plus bas
4bande 4 (panneau Malorie), colonne image466x596 (photo de fond).media-text__media 466x0hauteur nulle : la photo ne s'affiche pas du tout
7architecture du pied4 col : 324 (logo PDN 294x69 + « Vins de la Maison Gilliard » + logo Gilliard 180x48), 270 adresse, 148 liens, 473 newsletter ; reseaux 50x50 DANS la barre du bas ; bas = copyright a gauche / confidentialite a droite4 col : liens 190, newsletter 381, contact 286, reseaux 286 ; pas de colonne logo ; bas inversecomposition differente, pas un portage
8formulaire newsletter du piedchamp 472.5x54 pleine largeur + bouton 472.5x52 EMPILE dessous, fond rgb(252,141,163), 15px/700champ 268x52 + bouton 52x52 en ligne a droite, fond transparent, glyphe « ✓ »
9bande 2, mediadeux images 270x461.7 (@135 et @435)une seule 643x428.7 @77decale le bloc de 58px et le raccourcit de 33
10intitules du piedh2 44.8px Yeseva One BLANC, casse normaleh3 20.4px w500 ROSE MAJUSCULESquatre erreurs a la fois
11corps + CTA de bandep 25px/35px noir ; CTA aligne a gauche sur le textep 20.4px/30.6 rgb(74,74,82) ; CTA centrememe centrage errone en bande 4
12bande Instagramconteneur 1200, tuiles 232x232 x5, chaque tuile est un LIEN avec incrustation video/carrouselconteneur 1270, tuiles 246x246, simples div sans lien ni incrustationUNVERIFIED : la meme image revient dans 3 tuiles sur 5 (donnee de seed ou bug de gabarit ?)
13puces de pagination du hero50x10 @1190,620 (3 puces de 10px, pas de 20, decalage 200 a droite / 130 en bas)47x10 @1353,726 (decalage 40/24), puce active 11.5pxancrees sur la boite de padding au lieu de l'encart du live
14nav + langueitems colles, gouttiere 0px (Nos vins @421.4 -> Cocktails @518.7) ; FR est l'item de menu n°7, 16px, sans majuscules ni interlettrage, avec un deroulant FR/DEitems a margin 0 5px = 10px de gouttiere ; FR est une pilule 26.3x36 majuscule dans .site-header__utils⚠️ piege de portee : la gouttiere de 10px vient d'une correction mesuree sur GILLIARD (cont.13) et appliquee dans base/. Elle est FAUSSE pour PDN. Derive cumulee de -27px au premier item a +23px au dernier
15carte de vin, boutona.elementor-button 153x37 contenant une icone 13x13 ; carte 215x510 ; media aligne a gauche avec 30px de padding droitspan.g-card__link 132x39 sans icone ; carte 215x522 ; media centreecart titre->bouton 20px contre 9px chez le live, soit +12px par carte

Confirme CONFORME (ne pas toucher) : les decorations ::before/::after du hero (a 1px pres), tous les h2 a 57.12px Yeseva One, le titre du hero (410.4 @1440 / 446 @1920 / 63 @375), et les grilles de cartes cocktails/news 273x396 / 273x424.

UNVERIFIED : les etats interactifs des bandes 3 a 7 n'ont ete mesures qu'a 1440 ; le survol des tuiles Instagram et des liens du pied cote live n'a pas ete capture ; en local a 1024 les slides du hero rendent 1024x558 dans une section 1024x540 - 18px de debordement, cause non isolee.

B3. [AGENT] Listings et pages de contenu PDN - 15 defauts ​

⚠️ CORRECTION d'un item « connu » : la carte de listing n'est PAS ce que decrit pdn-resume.md ​

pdn-resume.md §4c annonce « image + sur-titre rose EVENT + titre Yeseva noir + extrait + fleche, transparent sur ambre », en grille. Mesure : c'est faux sur deux points.

  • Le live est une LISTE EN UNE SEULE COLONNE, un item par ligne a toutes les largeurs - pas une grille.
  • Il n'y a aucun sur-titre rose au-dessus du titre. L'ordre reel est image -> titre (Yeseva One) -> ligne meta (date + categorie) SOUS le titre -> extrait -> fleche, et la categorie est noire (#000000), pas rose. Le seul rose est a.link (#FC8DA3), une ancre de recouvrement invisible sur l'image, dont la couleur ne compte qu'au survol.

Specification retenue (live article.post_item.post_layout_excerpt) :

propriete37576810241440 / 1920
colonnes1111
boite de carte335708848848
gouttiere entre lignes3242.55050
image335x297.4708x444500x444500x444
regle d'image<img> a min(largeurNaturelle, colonne), ratio conserve. L'art des cocktails fait 500x444 -> plafonne a 500 des 1024
titreYeseva One 400 #11131A 17/2425/2928/30.838.39/42.23
date metaGothamPro 700 13/19.5 noir14/2114/2114/21
categorie metaGothamPro 700 12px, ls 0.7px, MAJUSCULES, noire
extraitGothamPro 400 noir 16/24.4817/26.8617/25.520.4/30.6
troncature de l'extraitaucun clamp CSS : extrait serveur ~30 mots + … litteral
flechea.post-more-link 18.2x20.3, glyphe fontello U+E9A4 11px #11131A ; le <span>Read More</span> est display:none
fond de cartetransparent (la bande derriere est #FFCC66)
survolimage scale(1.01) -> scale(1.07) en 0.5s, et a.link #FC8DA3 -> #F96683. Rien d'autre ne bouge

Notre carte (a.g-card--listing.g-card--blog) diverge sur presque tout : fond blanc (live transparent), media en background-image CSS et non en <img>, pastille 84.2x33 que le live n'a pas, titre GothamPro 300 au lieu de Yeseva One 400, chevron › en GothamPro 20.4px au lieu du glyphe fontello, ni date, ni categorie, ni extrait, et aucun etat de survol.

Defauts systemiques (une correction deplace plusieurs pages) ​

#elementlivelocalpages touchees
2bande de hero + introhero 541/419/419/335 ; l'intro est DANS le herohero 686/499/499/425 + une .rich-intro separee (+281 a +342)les 11 pages ; hero+intro 967 contre 621 @1440
9police de corps en mobileFAIT le 2026-08-01, voir §C11. Ce n'etait pas le corps seul : c'est le root qui descend a 16px sous 768 chez le live, donc tout le systeme rem.
14couleur du texte courantrgb(0,0,0)rgb(74,74,82)toutes
4largeur de la colonne de texte1290 (privacy) / 850 (article)722 partoutprivacy + les 2 articles
5bande « Articles récents »H3 + liste d'articlesabsenteles 2 articles : -902 @1024 / -386 @1440, et -1164 / -686
7habillage des champsfond transparent, bordure 0 0 1px, 16pxfond blanc, bordure 1px tout autour, 20.4px/contact/, /club/, newsletter du pied partout
12bouton d'envoi175x55, Krona One 14px, texte blanc sur transparent, bordure #C699FB -> #BB85FA au survol300x83, GothamPro 20.4px, contour #11131A -> rempli au survol/contact/, /club/, pied
8survol des cartesimage scale(1.01) -> scale(1.07) 0.5s + lien #FC8DA3 -> #F96683aucun changementcocktails, news, evenements, news-events, idees-cadeaux, goodies

Defauts par page ​

#pageconstat
1/club/le formulaire d'adhesion (11 champs) n'a jamais ete migre - <form> 616x581 chez le live avec Prénom+Nom sur une ligne, e-mail, adresse, NPA+Localité, date de naissance en trois champs JJ/MM/AAAA, bouton 616x52. Hauteur locale 2951 contre 4267 @1024
3privacyintitules : live H3 38.39px marge-bas 0 ; local H2 57.12px marge-bas 60. Six intitules x ~80px = l'essentiel des +1825 @1440
6/contact/live : formulaire 645 de large, 2 champs par ligne, textarea 645x99, bouton 175x55. Local : 873 de large, 5 lignes pleines empilees, textarea 873x328, bouton 300x83, plus un champ « Adresse » et une case de consentement que le live n'a pas
10goodies + idees-cadeauxFAIT le 2026-08-01, voir §C13. Colonnes, x, tuile et image identiques au live aux 4 largeurs.
11goodies + idees-cadeauxFAIT le 2026-08-01, voir §C13 - et le defaut principal n'etait ni le ratio ni les colonnes : c'etait le panneau blanc et le titre imprime deux fois.
13/contact/sous le formulaire, live = bande Instagram h346 + bande finale h522 + deux espaceurs de 120, page constante a 2545 de 1440 a 1920 ; local = une bande h1776 qui grandit avec la fenetre (3114 -> 3514)

✅ TRANCHE (§C3) : le texte de la page privacy est A PARITE - il n'y a rien a rapatrier. Corps reel du live 731 mots, corps reel local 732. Les 274 mots d'ecart brut etaient 209 mots de tableau d'inventaire des cookies genere par un plugin WordPress que nous ne faisons pas tourner, plus 66 mots de pied de page que le filtre de chrome ne captait pas cote live. Le defaut de cette page (n°3 ci-dessus) est typographique, pas editorial.

B1ter. ✅ CARTE D'ACTIVITE - CORRIGEE le 2026-08-01 (commit 9d8170c) ​

Re-mesure de premiere main sur le live des deux marques, accueil ET /activites/. B1bis avait raison sur les valeurs ; il manquait la structure exacte et deux defauts voisins.

Structure reelle du live : la bande d'adresse contient une rangee interne avec un <img> 18x18 puis un <span>, et c'est le span qui porte la typographie. Le 16px rgb(50,50,50) que deux commentaires du depot citaient est le style herite de la bande, que rien de visible n'utilise - les deux mesures s'etaient arretees a l'element exterieur.

gilliard livechevaliers live
bande406x42, bg #c3baa7, pad 8 0 8 22406x41, bg #e4e4e4, meme padding
repereADDRESS_01-1.png 18x18location-3.png 18x18
texte12.8px rgb(142,120,76)16px rgb(0,0,0)
boite de ligne interne2625

Les deux valent 0.8em du corps de leur marque et var(--bs-primary) de leur marque : une seule regle de base sert les deux, et a 375 elle suit toute seule le corps de 15px vers 12px. Aucune regle white-space. Le repere est un ::before inline-block en alignement de base delibere - c'est son depassement de ~2px au-dessus de l'ascendante d'une ligne de 24 qui produit la rangee de 26 et la bande de 42.

Deux defauts voisins corriges dans le meme commit :

  • le chevron. Le .title-wrap du live porte ::after ">" scaleY(2) a right:20px, glissant a 35px au survol - identique aux hero-boxes. La carte d'activite n'en avait aucun ; en listing elle heritait au contraire du chevron de CORPS, centre sur titre + adresse. Un seul, sur le titre.
  • le chevauchement du bloc titre sur la photo (position:relative + marge haute negative).

⚠️ Un deuxieme commentaire « mesure » du depot etait faux : themes/chevaliers/main.scss affirmait « chevaliers est PLAT (pas de bande) ». La bande existe bien, en rgb(228,228,228).

Verification : bande 42/42, y921/y921, titre y841/y841, carte 411 contre 410.7 (gilliard) ; bande 41, 16px noir, carte 387.7 contre 387.7 (chevaliers). Ferme B1bis et B4-3.

B1bis. ⚠️⚠️ CORRECTION DE B1 - le nowrap N'EXISTE PLUS, j'avais tort ​

B1 ci-dessous est FAUX sur son point central et reste ici comme trace de l'erreur. J'y ecrivais que notre .g-card--activity .g-card__location est en white-space:nowrap et tronque. Je l'avais pris du message du commit 9d16cd5 et de la memoire du projet, PAS d'une mesure - exactement l'erreur contre laquelle ce depot met en garde (« jamais un commentaire de code, jamais un message de commit : la source de verite est le DOM du live et le CSS calcule »). Le nowrap a ete retire depuis, probablement en cont.21.

Mesure directe du local, 2026-07-30 (audit_cardtitle.mjs sur gilliard.localtest.me @1440) : .g-card__location -> white-space: normal, 16px/24px, rgb(50,50,50), boite 406x40. Les deux cotes passent donc a la ligne. Le vrai defaut est ailleurs :

proprietelivelocal
taille de police12.8px (et 12px @375, parce que le corps du live y passe a 15px)16px a toutes les largeurs
couleuror rgb(142,120,76)gris rgb(50,50,50)
icone<img> epingle de carte 18x18 avant le texteabsente
boite de ligne de la bande26px (bande 8+26+8 = 42, ou 68 sur deux lignes)24px (bande 40 / 64 / 88)
white-spacenormal (aucune regle)normal - conforme

Le live ne rend une seule ligne a 1440/1920/375 que parce que la chaine fait 283px a 12.8px et tient dans la boite ; il passe tout seul a deux lignes a 1024 et 768. Aucune regle nowrap nulle part, d'aucun cote. La correction qui satisfait les trois pages (accueil, activites, oenotouristiques) : font-size: 0.8rem, couleur or, retablir l'epingle 18x18, boite de ligne a 26px, et ne poser aucune regle white-space.

Note : le token or existe deja (themes/gilliard/_overrides.scss:40, « chevaliers uses grey ») mais n'atteint pas cette bande. Une autre variante de .g-card__location sur la meme page rend bien en 15px or - donc c'est un probleme de portee de selecteur, pas de token manquant.

Ce qui RESTE vrai de l'entree d'origine (mesure, pas suppose) : le .title-wrap du live porte position:relative + une marge haute negative et chevauche l'image, le notre non ; le media 406x271 est conforme ; et le decoupage de bande differe - le live a DEUX sections (tete section.experiences-2 1440x381 @y1962 + cartes 1440x482 @y2343 = 863) la ou nous n'en avons qu'une de 839.

Garde-fou a conserver : min-width:0 sur l'element de grille doit RESTER (il a corrige un vrai debordement horizontal a 768 dans 6f5a8a5).

B4. [AGENT] gilliard - systemique et par page ​

Contenu GELE : les ecarts de copie sont en fin de section et ne sont PAS a corriger.

#elementlivelocalportee / pages
1colonne de texte richesuit le conteneur : 1736 @1920 (paragraphe 870)plafond dur max-width:772px (paragraphe 726)base - toute la famille des ecarts >=1440 : nos-valeurs -84, a-propos -104, foudres -133, vinotheque -93, ambassadeurs -60, activites -122, oeno -124, team -54 @1920
2texte riche en 2 colonnes a 768paragraphe 374 de large1 colonne (674)base - nos-valeurs -131, a-propos -263, foudres -259 @768
3bande d'adresse de carte12.8px or + epingle 18x18 + boite 26px16px gris, sans epingle, boite 24pxaccueil + activites + oenotouristiques (cf. B1bis)
4marge des paragraphes16px 00 0 16pxbase - casse aussi la fusion de marges entre paragraphes
5interlignage du corps @37515px/24px15px/22.5pxbase
6h1 du page-heromarge 32.16px 0 ; 30px/37.5px @375marge 0 ; 30px/normal @375base - titre mal centre dans la bande de 400
7intitule de colonne du piedH4 16px/24px, marge haute 21.28H3 16px/19.2, marge basse 21.6base
8padding du pied45 haut + 45 bas (35/45 @1024)64 + 56base (~+19 @1440, +29 @1024)
9decoupage interne du pied @375conteneur 1093 + bandeau 118conteneur 968 + bas 169base. ⚠️ les totaux se compensent (1211 vs 1201) : la porte de hauteur ne le voit pas
10controle newsletter du piedchamp 280x50 @x278 + envoi 48x50champ 268x52 @x295 + bouton 52x52base

Sous le top 10 : le .title-wrap du live a margin-top:-10px; position:relative (chevauche l'image), le notre non ; le h3 de carte du live est 16px/24px w300 et passe a 18px/27px @1920, le notre reste 16px/22.4px partout ; le texte de pastille du live est 16px, le notre 12.8px.

Par page : privacy +1375 @375 (pire page du lot, parite >=1024) · en-primeur +227 @1440, le NOMBRE de bandes correspond, l'exces est DANS les 4 blocs (UNVERIFIED lequel) · blog, 80px d'espacement haut manquant sur la bande de listing · accueil @375 : cartes +18/carte, media-text +138, gammes +58, hero-boxes +44 · lieux +13/carte x10 @375 · contact, bande decalee de +91 @1440 mais les boites de champs sont exactes · gammes, H3 live contre H2 local + 34px de marge en trop · cgv +200 @1024 / -89 @1920.

Confirme CONFORME : l'echelle de conteneurs (720 / 1350 / 1736) est exacte partout ; la parite de survol est propre sur les 10 cibles ; la geometrie des champs du formulaire de contact est exacte.

Derive de contenu (non actionnable) : blog 8 articles live contre 6 local (une rangee entiere) ; corps d'article plus court ; cartes 1 et 3 de l'accueil renommees sur le live ; /team/ porte un h2 d'intro que le live n'affiche plus.

B5. [AGENT] chevaliers - systemique et par marque ​

La police passe : les deux cotes ne rapportent que TwCenMTStd-Light.

Porte structurelle (local - live, 12 pages x 5 largeurs) - les trois pires : domaines+49/-260/-41/+417/+241, evenements +120/-30/-59/-263/-342, caves-ouvertes-143/-356/-408/-269/-303, et privacy +2230 @375.

#elementlivelocalportee
1hauteur de l'en-teteFAUX POSITIF - CLOS, voir §C4. Mesure aux 5 largeurs, aux deux etats de defilement, accueil ET page interieure, les deux marques : l'en-tete est exact.
2interlignage du corps @37518px/24px18px/21.6pxbase - aussi gilliard (15/24 contre 15/22.5). Meme cause que gilliard #5
3hauteur du pied1120.6/911.9/457.2/440/4101096.6/875.6/421.7/391.7/391.7base - trois causes empilees : boite de ligne des liens 30 contre 21, marge d'intitule 26.6 haut ET bas contre 0/22, et le pied du live retrecit encore de 440 a 410 entre 1440 et 1920 alors que le notre est fige
4reseaux du pied3 <img> 24x24 (icon-facebook/instagram/linkedin.png)des libelles texte, ancres 108x24 sans iconebase
5ombre + survol des cartesFAUX POSITIF - CLOS, voir §C2. Le live peint rgba(0,0,0,.16) 0 0 99px au repos et rgba(0,0,0,.1) 0 5px 25px au survol sur div.box ; notre CSS est deja exact aux deux etats. Ne rien changer. Seul residu : timing ease-out contre ease (-> 4f).
6couleur des liens de cartergb(50,50,50)rgb(155,155,155)base - lie au token gris du corps au lieu de #323232
8formulaire newsletter du piedchamp 345x56 + envoi 46x56, rangee a x278champ 268x52 + 52x52, a x295base
9.btnmargin-top: 20px0base - perdu partout ou un bouton suit du texte
10modele de bloc richIntroles intitules sont fondus dans un seul conteneurbandes section.rich-intro autonomes de 406-436px chacune (domaines : 4 bandes = 1684px @1920)base - UNVERIFIED sur gilliard

Items connus - verdict : cta-banner 585 CONFIRME et bisecte : c'est une regle propre a chevaliers a partir de ~1800 (65vh), pas une longueur de contenu - gilliard reste a 540 @1920 · domaines CONFIRME, et la cause est exactement les bandes rich-intro autonomes · icone de compte PERIME : le live n'a que le panier, et nous aussi desormais ; seul l'art du panier diffe (<img> 34x41 contre <svg> 28x28) · evenements +598 @375 PERIME : c'est +120 aujourd'hui, et le surplus est passe cote desktop (-263/-342), lie au nombre et a la hauteur des rangees, pas a la frise.

Par marque : marge haute du cta-banner 100 live contre 150 local @375 · /logement/ +200 et demarre 40px trop haut · /caves-ouvertes/ porte une bande d'intro vide de 392px que le live n'a pas · h3 de detail d'evenement 22.5/36 w400 contre 20/30 w300 et colonne 146px plus etroite · /privacy/ @768 notre corps est inset mar 0 60 (584) dans un conteneur de 720 que le live remplit · /gammes/ decale de +22px · /activites/ espaceur de 60px manquant · case de consentement 13x24 live contre 13x13 · hero d'accueil -52px (masque, mais la hauteur de bande cascade sur toute la page).

C. CONTRADICTIONS ENTRE AGENTS - LES 3 SONT TRANCHEES (session principale, 2026-08-01) ​

Mesure de premiere main, CDP, live et local cote a cote. Les trois verdicts vont dans le meme sens : c'etait l'AGENT qui avait tort a chaque fois, jamais la note du depot. Sondes conservees dans le scratchpad de session ; la methode est reproduite ci-dessous pour chaque point.

C1. Souligne de navigation - l'agent « chrome » avait raison ; l'agent chevaliers a produit un FAUX NEGATIF ​

Le live peint bien un souligne de nav sur gilliard ET sur chevaliers. L'agent chevaliers l'a rate parce qu'il a force :hover sur le <a>, alors que le live le declenche depuis le <li> parent. C'est exactement le cas que le plan signalait (« etats declenches par le parent ») et la raison pour laquelle une mesure de survol doit toujours forcer aussi les ancetres.

Regle du live, identique sur les deux marques (seule la couleur change) :

css
.main-navigation > div > ul > li > a::after {
  content:""; display:block; position:absolute;
  width:0%; height:1px; background:#8E784C;   /* #000000 sur chevaliers */
  left:0; right:0; margin:auto; bottom:10px;
  transition: all .2s ease-in-out;
}

Mesure aux 4 etats forces (a:hover seul / li:hover / ul:hover / souris reelle) :

live gilliard « Contact »live chevaliers « Activités »local (les 2 marques)
repos0 x 1px0 x 1px0 x 1px
a:hover force0 x 1px (aucun effet)0 x 1px (aucun effet)78.27 / 72.08
li:hover force46.63 x 1px43.53 x 1pxidem que a:hover
souris reelle46.6343.5378.27 / 72.08

⚠️ Cela corrige AUSSI la note B0-1, qui est FAUSSE. B0-1 affirmait « notre CSS EST left-origin, comme le live sur les trois marques ». Le live n'est pas left-origin : left:0; right:0; margin:auto sur une boite de largeur definie la centre, donc le souligne du live croit du centre vers l'exterieur. Le notre est left:0; width:0 -> calc(100% - 15px), donc left-origin. La note de cont.19 (« centre-out a la demande de l'utilisateur alors que le live est left-origin ») avait donc le probleme a l'envers : c'est le LIVE qui est centre-out.

Notre regle actuelle : .site-menu__link::before { background:currentColor; bottom:10px; content:""; height:1px; left:0; position:absolute; transition: width .2s ease; width:0 }.

Quatre defauts reels a corriger (portee base, les deux marques) :

  1. origine : le live est centre (left:0; right:0; margin:auto), nous sommes ancres a gauche ;
  2. largeur finale : le live s'arrete a la largeur du texte (46.63 / 43.53), nous allons a calc(100% - 15px) (78.27 / 72.08) - donc trop large ET decale de ~23px a gauche ;
  3. easing : live ease-in-out, nous ease (defaut) ;
  4. declencheur : live li:hover, nous a:hover. Visuellement equivalent tant que le <li> epouse le <a>, mais a aligner pour que la gouttiere du <li> declenche aussi.

::after chez le live contre ::before chez nous : sans consequence, un seul des deux sert.

C2. Ombre des cartes - cont.19 avait raison ; l'agent chevaliers avait tort ​

Le live chevaliers peint bien une ombre de carte. Mesure sur https://chevaliers.ch/fr/activites/, element div.box (406x388) :

livelocal (a.g-card--activity, 406x371)
reposrgba(0,0,0,0.16) 0px 0px 99px 0pxrgba(0,0,0,0.16) 0px 0px 99px 0px conforme
survolrgba(0,0,0,0.1) 0px 5px 25px 0pxrgba(0,0,0,0.1) 0px 5px 25px 0px conforme
transitionall 0.3s ease-outbox-shadow 0.3s ease

L'ombre est deja exacte, au repos comme au survol. NE PAS LA RETIRER. B5-5 est un faux positif et doit etre lu comme clos. Seul residu, minuscule : la fonction de timing (ease-out contre ease) - a ranger avec les etats d'interaction (4f), pas avec les ombres.

Pourquoi l'agent a vu none : sa recherche de cartes n'a rien matche du tout sur la page qu'il a sondee (le live n'utilise ni .card ni article ici, mais div.box), et « aucun element trouve » a ete rapporte comme « aucune ombre ».

C3. Volume de texte de la confidentialite PDN - les deux mesures precedentes concluaient mal ; le texte est A PARITE ​

Comptage du texte reellement peint (marche sur les noeuds texte + Range.getClientRects(), donc ni display:none ni boite vide), live contre local, @1440 :

mots
live, total rendu1006
dont tableau d'inventaire des cookies (genere par le plugin GDPR Cookie Consent : pll_language, cookielawinfo-checkbox-*, _ga, _gid, _gat_gtag_UA_...)-209
dont pied de page passe au travers de mon filtre de chrome cote live (le pied du live n'est pas dans un <footer>)-66
live, corps reel731
local, corps reel732

Ecart : +1 mot. Il n'y a rien a rapatrier. Les 274 mots « manquants » etaient 209 mots de tableau de plugin plus 66 mots de pied non filtre. L'agent (1028 contre 812) mesurait le meme artefact ; mon audit §A3 contre l'export (1701 contre 1659) mesurait autre chose encore mais concluait juste : parite.

Deux consequences :

  • Aucune correction de contenu sur cette page. Elle sort du perimetre de la phase 3.
  • Le tableau des cookies du live decrit des plugins WordPress que nous ne faisons pas tourner (Polylang, GDPR Cookie Consent, GA universel) et il est en anglais. Le reproduire serait de la fausse documentation. Deviation deliberee a consigner dans assets-substitues.md.
  • Le defaut B3-3 de cette page reste entier et reste actionnable : il est typographique, pas editorial (intitules H2/57.12px marge-bas 60 chez nous contre H3/38.39px marge-bas 0 sur le live, six intitules = l'essentiel des +1825px @1440).

C4. Hauteur de l'en-tete (B5-1) - FAUX POSITIF, rien a corriger ​

C'etait l'item n°1 par rendement de l'ordre de reprise. Mesure de premiere main : il n'existe pas. header.site-header (le live utilise le meme nom de classe que nous), hauteur de boite :

375768102414401920
gilliard live / local, haut de page72 / 7280 / 8080 / 80110 / 110110 / 110
gilliard live / local, defile52 / 5151 / 5151 / 5167 / 6767 / 67
chevaliers live / local, haut de page77.78 / 7880 / 8080 / 80110 / 110110 / 110
chevaliers live / local, defile57.78 / 5756.78 / 5756.78 / 5767 / 6767 / 67

Verifie sur l'accueil et sur /contact/ des deux marques : memes valeurs. Ecart maximal 1px, sur l'etat defile a 375/768/1024 uniquement, du a l'arrondi de padding (le live pilote la hauteur par padding:15/15 puis 5/5, nous par une hauteur posee - resultat identique).

Les chiffres « live » de l'agent (66.6/67/67/83/82.9) ne correspondent a aucun des deux etats que je mesure. Le plus probable : il a lu un enfant de l'en-tete (nav.main-navigation fait 1200x57 @y27 sur gilliard, donc bas a 84) et l'a pris pour la bande. Meme mode d'echec que C1 et C2 : le mauvais element.

C5. Le pied de page - CORRIGE le 2026-08-01, et ce qui RESTE est explique ​

Mesure de premiere main du pied du live aux 5 largeurs sur les DEUX marques, puis correction, puis re-mesure. Le modele du live, identique sur gilliard et chevaliers, tout derivant de la taille de corps de la marque :

live
bande footerpadding: 0 - le rythme vertical appartient au wrapper interne
wrapper interne45px 0 a partir de 1200 ; 35px 16px 45px entre 768 et 1199 ; 35px 16px 32px a 375
colonnes2 / 4 / 3 / 3 douziemes, padding: 0 8px chacune, aucune gouttiere, rangee tiree par margin: 0 -8px
intitules<h4>, line-height: 1.5, margin: 1.33em 0 (les deux cotes)
lien de menudisplay: block, line-height: 1.5 ; li margin-bottom:15px + padding-right:15px ; ul margin: 1em 0 + padding-right: 25px (les deux a 0 sous 768)
champ newsletterpadding: 12px 15px sur une ligne 1.5 + 1px de bordure -> la hauteur du live tombe toute seule : 50 (gilliard 16px), 56 (chevaliers 20px), 48.5 et 53 a 375
bouton d'envoigilliard 48x50 sans bordure, superpose DANS le bord droit du champ (le controle fait 280 de large, pas 328) ; chevaliers 46x56 borde de noir, a cote, l'ensemble a 90 % de la colonne plafonne a 453
couleur du champgilliard OR, chevaliers NOIR - la base reste noire, gilliard surcharge
ligne socialeline-height: 30px absolu sur les deux marques et les 5 largeurs ; items espaces de 10px
ligne de contactitems espaces de 10px ; les lignes a icone sont sur une boite de 30px, les lignes d'adresse sur 24
barre du baspadding: 0 sur la bande ; deux colonnes 7/5, chacune avec son propre padding: 15px 0 - c'est ce qui fait la barre de 54px a 1440
ligne du piedline-height: 24px absolu sur les deux marques (donc PAS 1.5 : chevaliers tourne un corps de 20px)

Resultat mesure (hauteur totale du pied, live contre local) :

375768102414401920
chevaliers, avant-24-36.3-35.5-48.3-18.3
chevaliers, apres-70.6-39.4-7.2-1.0-1.0
gilliard, apres-112-47.4+15.5-7.5-7.5

⚠️ Les totaux ont EMPIRE a 375 alors que chaque mesure interne s'est rapprochee. Ce n'est pas une regression, c'est la fin d'une compensation que B4-9 avait deja signalee : notre padding de 64+56 masquait des colonnes trop courtes. Le padding est maintenant juste (45/45) et le manque de contenu est visible. Il est explique, et les trois causes sont hors de notre portee ou gelees :

  1. Le live porte un badge Trusted Shops (minimized-trustbadge-inline-horizontal, 37px de haut plus 40 de marge haute et 20 de marge basse = 97px) dans sa colonne « Sur les reseaux ». C'est lui qui fixe la hauteur de rangee du live a 1440 (273.5 contre nos 266) - d'ou le -7.5 residuel de gilliard, qui est donc du 1:1 atteint. Widget tiers, non reproduit.
  2. Nos libelles de menu de pied sont plus longs que ceux du live (contenu gele) : a 1024 ils passent a la ligne dans une colonne de 2/12 et rendent notre pied plus haut (+15.5).
  3. Notre adresse seedee est coupee en deux lignes (« Rue de Loèche 70 » / « 1950 Sion ») la ou le live la rend sur une seule. Une ligne de plus par pied. A traiter au prochain re-seed - c'est notre choix d'ecriture, pas une derive du live.

Lignes du registre que cela ferme : B1-6, B1-7, B1-9, B1-10, B4-7, B4-8, B4-10, B5-3, B5-8, et B1-5 (le champ or de gilliard). B1-8 (15 contre 14 liens) est du contenu gele. B5-4 (reseaux du pied de chevaliers en libelles texte) est PERIME : les glyphes PNG sont rendus, verifie a la capture.

C6. ⚠️ POURQUOI DES DEFAUTS VISIBLES SURVIVENT A UNE MESURE « EXHAUSTIVE » ​

Question posee par l'utilisateur le 2026-08-01, apres avoir signale un defaut evident sur la bande « Nos Activites » que toutes les passes precedentes avaient laisse passer. La reponse est structurelle et vaut pour tout le reste du chantier.

1. La porte pixel est LOCAL contre LOCAL. baseline.mjs --against ref prouve que rien n'a change depuis la derniere execution. Elle ne dit rien sur la conformite au live. Seules les sondes comparent au live.

2. Une sonde renvoie un nombre pour le selecteur qu'on lui donne - y compris le mauvais. C'est le mode d'echec de C1, C2, C4 et des deux commentaires « mesures » du depot corriges en B1ter. Un chiffre issu du mauvais noeud ressemble exactement a une mesure.

3. La porte de hauteur compare des TOTAUX, donc les erreurs se compensent. Deja note en B4-9, et rencontre deux fois de plus le 2026-08-01 : le pied paraissait « a 10px pres » parce qu'un padding trop grand masquait des colonnes trop courtes ; la grille d'activites paraissait juste a 1024 parce qu'un pas de rangee 22px trop grand compensait des cartes trop courtes.

4. ⭐ Et surtout : un defaut de COMPOSITION n'est faux sur AUCUN element. Le halo des cartes d'activite en est le cas d'ecole. Media 406x271 aux x67/517/967, bande d'adresse 406x42 a Y2690, titre a Y841 : chaque element etait exact au pixel contre le live. Le defaut etait que l'ombre de 99px etait portee par la colonne (450x411) au lieu de la carte (406x389). Aucune sonde par element ne pouvait le voir, parce qu'aucun element n'etait faux.

La regle qui en decoule - a appliquer avant de declarer une bande conforme ​

  1. Capturer la BANDE ENTIERE, live et local, au meme cadrage et au meme defilement (viewport, pas recadrage d'element : un recadrage d'une carte ne peut montrer ni les gouttieres, ni le fond derriere, ni un filet qui traverse trois cartes). Sonde : regionshot.mjs du scratchpad, a porter dans probes/.
  2. Passer diff.mjs --report-only et LIRE le registre de couverture, pas seulement le compte de pixels : ses seaux liveOnly / localOnly / styleDiffs enumerent tous les noeuds du live, donc ils ne dependent pas de ce que j'ai pense a nommer. C'est l'outil qui a trouve l'interligne de titre a 22.4 contre 24 en trois secondes.
  3. Verifier quel ELEMENT porte l'ombre, le fond et la bordure, pas seulement leurs valeurs. Une valeur juste sur la mauvaise boite est un defaut visible.
  4. Quand un total se rapproche apres une correction interne, se mefier : verifier que ce n'est pas une compensation. Deux erreurs de signe oppose passent la porte.

C7. ⭐ LA MESURE QUI MANQUAIT - sweep.mjs sur les 3 marques contre le LIVE (2026-08-01) ​

L'utilisateur : « tu dois correspondre au live, alors pourquoi ne verifies-tu pas le live ? ». Reponse honnete : diff.mjs - le seul outil qui compare vraiment au live, en enumerant tous les noeuds de son DOM - existait depuis le debut et n'avait ete lance qu'une fois. Tout le reste etait « je choisis un element que je soupconne, je le mesure, je le corrige ». On ne trouve ainsi que ce a quoi on a deja pense.

Diff pixel contre le live, 52 pages @1440 (referentiel a garder ; relancer apres chaque lot) :

marquepiremeilleur
gilliard (20)emploi 42.4 %, blog 33.0 %, lieux 30.7 %newsletter 2.4 %, gammes 3.5 %
chevaliers (12)accueil 25.4 %, domaines 21.7 %activites 2.7 %, privacy 4.1 %
pdn (20)idees-cadeaux 56.0 %, news-events 52.0 %article-cucumber 29.6 % - aucune page sous 29 %

Ce que l'agregation des registres a livre immediatement, et qu'aucune sonde ciblee n'avait vu :

  • les icones utilitaires de l'en-tete n'etaient pas celles du live (24 + 12 pages) -> c2ba7a0 ;
  • le pied de PDN manquait en entier, sur 25 pages sur 25 -> 792e901 ;
  • l'adresse postale coupee en deux elements alors que le live l'ecrit d'un bloc (les 3 marques) ;
  • l'interligne du titre de carte a 22.4 contre 24, trouve en trois secondes.

⚠️ Et un defaut du HARNAIS lui-meme, qui invalidait la porte : le live sert un popup Mailchimp (.mc-modal + .mc-modal-bg, un fond qui couvre TOUT le viewport) de facon non deterministe et declenchee au defilement. La meme page inchangee a mesure 5.86 %, puis 16.66 %, puis 5.86 %. Une vraie regression pouvait donc se cacher dans ce bruit, ou un fantome envoyer chasser du vent. Masque sur les trois marques ; trois executions donnent desormais 5.7179 / 5.7179 / 5.7137.

⚠️ Limite a garder en tete : diff.mjs rapporte « LOW ALIGNMENT » sur la plupart des pages (50-77 %), parce que notre DOM est bien plus maigre que celui de WordPress et que le contenu est gele sur deux marques. Sur ces pages, le nombre de PIXELS et les seaux du REGISTRE sont fiables ; le diff de proprietes par noeud ne l'est pas.

La commande, a lancer apres chaque lot de corrections :

bash
cd tools/fidelity && MSYS_NO_PATHCONV=1 node sweep.mjs <marque> --widths 1440

C8. Deviations CONSIGNEES puis CORRIGEES (2026-08-01, 3994a28 et b086f29) ​

Remarque de l'utilisateur : consigner un ecart n'est pas le corriger. Les items ci-dessous etaient ecrits dans ce registre et laisses en l'etat ; ils sont faits.

itemetat
Bouteille en surimpression du hero de vinFAIT (b086f29) - 290.3x566.9 a x649,Y177, les valeurs exactes du live
B1-1 anneau de focus des champsFAIT - outline: 1px auto, box-shadow: none, comme le live
B1-18 transition et padding des boutonsFAIT - all .3s ease-in-out, 10px 20px, pas d'anneau de focus
§C2 transition des cartesFAIT - all .3s ease-out et non la seule ombre
B2-7 reseaux sociaux de PDN dans la barre du basFAIT - partial partage, un seul emplacement rendu, pilote par socialsInBottomBar
B1-4 glyphes sociaux de PDN absentsFAIT - SVG extraits du DOM du live et self-hostes

| Repartition 3+1 de ice-0-0 | FAIT - columnBreak sur factsPanel ; verifie 3 a gauche, 1 a droite, comme le live | | Decoration raisins.png de la bande « Détails » | FAIT - fond du second conteneur, 18 % en bas a droite, absent a 1024 comme sur le live |

Le point de rupture des colonnes est devenu une donnee et non une deduction : les colonnes du live sont des conteneurs auteurs qui gardent la repartition de leurs sept widgets d'origine meme quand certains sont masques, et le scrape ne porte que les faits VISIBLES - le chiffre ne pouvait donc pas en etre deduit. Par defaut la moitie arrondie au superieur, ce qui redonne le 4+3 du live sur les six autres pages.

4c RE-LOCALISE (2026-08-01) - ce n'est PAS le mediaText, c'est le richIntro ​

B4-1 accusait « la colonne de texte riche » sans dire laquelle. Mesure page par page a 1920 :

pagelivelocalverdict
/a-propos/540 @x256540 @x256identique
/nos-ambassadeurs/540 @x256540 @x256identique
/vinotheque/870 @x525726 @x597c'est ici

Les rangees mediaText sont donc justes partout ; le defaut est le bloc richIntro, dont base/sections/_rich-intro.scss fixe max-width: 788px. Mesure de la colonne d'intro du live sur /vinotheque/, en largeur de paragraphe :

102414401920
live514741.5870
notre plafond (788 - 8x2 - 15x2 = 742)742742742
7/12 du conteneur, moins 46514 ✓741.5 ✓966.7 ✗

Donc : notre 788 a ete mesure a 1440, ou il est exact, et il est fige. Le live suit une PROPORTION du conteneur - 7/12 reproduit 1024 et 1440 exactement. Nous sommes donc trop larges a 1024 (742 contre 514) et trop etroits a 1920 (742 contre 870).

1920 est desormais explique : ce n'est pas une exception a la regle, c'est la seule largeur ou le plafond de 900px de .title-text MORD. La chaine complete du live :

.col-md-7    flex-basis 58.3333 % de la ROW, padding 0 8px
.title-text  max-width 900px, CENTREE, padding 0 15px
p            remplit la boite de contenu de .title-text

1024   960 x 7/12 = 560   -> 544   -> 544              -> 514
1440  1350 x 7/12 = 787.5 -> 771.5 -> 771.5            -> 741.5
1920  1736 x 7/12 = 1012.7-> 996.7 -> **900 plafonne** -> 870

⚠️ TENTATIVE FAITE, ANNULEE - et voici pourquoi, pour que la prochaine ne la refasse pas. Poser max-width: 58.3333% sur .rich-intro ne marche pas : notre arbre n'est pas celui du live.

NOUS  section.rich-intro (1440, pleine largeur) > div.container (1350) > __body > p
LIVE  div.container (1350) > div.row > div.col-md-7 (787.5) > .title-text > p

Le pourcentage se resout donc contre 1440 et non contre 1350 : mesure, il donnait 849 au lieu de 787.5, et 787.3 de paragraphe au lieu de 741.5 - une regression de 46px a 1440, sur chaque page a richIntro des DEUX marques. Revenu au 788 fige, qui est exact a 1440.

✅ CORRIGE le 2026-08-01. La proportion porte desormais sur .rich-intro__body, seul enfant direct du .container, ou 100 % vaut bien la largeur du conteneur : width: min(calc((100% + 16px) * 0.583333 - 16px), 900px).

Le + 16px est mesure, pas devine : chez le live la colonne est un pourcentage de la ROW, et la row annule le padding de 8px du conteneur par une marge negative - sa base fait donc 16px de plus que la boite de contenu contre laquelle notre pourcentage se resout. Un 58.3333 % nu donnait 535 et 762 la ou le live fait 544 et 772 : un manque CONSTANT de 9.5px aux deux largeurs, signature d'un ecart absolu et non proportionnel.

Le titre reste inline-block centre - aucune des cinq pages qui portent ce bloc n'a un titre assez long pour atteindre la largeur de colonne, et lui poser une largeur casserait le centrage de son souligne.

Verifie, .title-text puis paragraphe, live contre local :

102414401920
live544 @x240 / 514 @x255772 @x334 / 742 @x349900 @x510 / 870 @x525
local544 @x240 / 514 @x255771 @x334 / 741 @x349900 @x510 / 870 @x525

Non-regression : sweep complet des deux marques a 1440 identique au referentiel §C7 (gilliard emploi 42.46 contre 42.4, blog 32.95 contre 33.0, lieux 30.72 contre 30.7, newsletter 2.41 contre 2.4 ; chevaliers accueil 25.36 contre 25.4, domaines 21.65 contre 21.7, activites 2.69 contre 2.7, privacy 4.12 contre 4.1) - ce qui est attendu, puisque 788 etait deja la valeur juste A 1440.

C9. CARTE DE LISTING PDN - specification VERIFIEE de premiere main (2026-08-01) ​

§B3 venait d'un agent. Re-mesuree moi-meme sur https://portedenovembre.ch/cocktails/ aux quatre largeurs. §B3 est juste sur l'essentiel (une seule colonne, titre Yeseva One, categorie noire, fond transparent) ; les valeurs ci-dessous sont celles a construire, deux corrigent §B3.

37576810241440
carte335x542.4 @x20768x653.5 @x0848x710.3 @x88848x740 @x296
fond de cartetransparenttransparenttransparenttransparent
image (<img>)338.3x300.4505x448.4505x448.4505x448.4
titre h3 Yeseva One w400 rgb(17,19,26)17/2425/2928/30.838.39/42.23
.post_meta GothamPro w400 noir13/19.514/2114/2114/21
fleche a.post-more-link 18.2x20.3Krona One 13px/20 rgb(17,19,26)idemidemidem
pas entre cartes574.4 (ecart 32)696 (ecart 42.5)710.3 (ecart 0)740 (ecart 0)

⚠️ Deux corrections a §B3 : la fleche est en Krona One 13px, pas un glyphe fontello de 11px ; et l'image est 505x448.4 des 768 (pas seulement a partir de 1024).

Notre carte diverge sur presque tout (mesure locale @1440) :

livenous
carte848x740 @x296, fond transparent848x824.9 @x318, fond BLANC
media<img> 505x448.4.g-card__media 848x752.3, en background CSS
titreYeseva One w400GothamPro w300 (la taille, elle, tombe juste : 38.42/42.26)
meta / extrait / flechepresentsabsents tous les trois
pas740, ecart 0864.9, ecart 40

Ce n'est donc pas qu'un travail de CSS : la ligne meta (date + categorie), l'extrait et la fleche n'existent pas dans notre gabarit. L'extrait est en outre contraint par §A5 - seuls 4 des 30 items ont un excerpt rempli, les autres doivent le deriver du corps.

Portee : cocktails, news, evenements, news-events, idees-cadeaux, goodies - les six pires pages PDN du referentiel §C7 (48 a 56 %). C'est le plus gros levier restant de la marque.

C10. CARTE D'ARCHIVE PDN - construite, et la REGRESSION qu'elle avait posee sur Gilliard ​

Suite de §C9. En construisant l'extrait de la carte, deux choses sont apparues qu'aucune mesure par element n'avait signalees.

1. L'extrait etait vide parce que le CHAMP est vide. childListing derivait le resume du seul alias body, et sur PDN ce champ est volontairement vide : les articles sont ecrits en BLOCS, le texte vit dans le premier richIntro de contentBlocks. La carte perdait donc 146px des 740 du live. Resolu comme le fait WordPress, en trois temps : extrait manuel (articleFields.excerpt, nouveau - seuls les 4 cocktails en portent un dans l'export, et ce n'est pas le debut de leur corps), sinon body, sinon le texte riche des blocs. La troncature devient une donnee de bloc (childListing.excerptWords) : 16 mots mesures sur /blog/ de Gilliard, 30 sur chaque archive PDN.

2. ⚠️ La ligne meta ajoutee par ff70347 etait posee sur cards-blog, donc sur GILLIARD aussi. Capture d'ecran a l'appui : chaque carte du blog Gilliard imprimait « 1 janvier 0001 » suivi du nom de categorie, a cote du titre, et son « Lire plus » avait ete remplace par un chevron ›. Le live Gilliard n'a ni date ni categorie dans le corps de sa carte (mesure du 2026-08-01 : div.box > image + pastille + h3 + p d'extrait + p.read-more-article « Lire plus », rien d'autre). Deux causes cumulees :

  • Value<DateTime?>("publishDate") renvoie default(DateTime) et non null quand la propriete est vide - d'ou l'an 0001. publishDate n'etait seede nulle part, sur aucune marque ;
  • l'archive PDN et la grille blog de Gilliard partageaient un seul layout.

Correction structurelle : nouvel affichage cards-archive, distinct de cards-blog. La carte d'archive porte sa propre classe g-card--archive, sa structure et son rythme vivent dans base/sections/_listing.scss (tableau de mesures aux 4 largeurs), la peinture de marque dans themes/pdn/_overrides.scss. publishDate est desormais seede depuis l'export WXR, ce qui repare d'un coup la date affichee et le tri date-desc (sans elle, tous les articles se comparaient egaux).

Mesure @1440, carte de /cocktails/ :

liveavantapres
carte848x740 @x296848x593.9 @x318848x739 @x296
media500x444 (crop 505x448 cale a GAUCHE)505x448 pleine boite500x444
titre+474 du haut de carte-+474
ligne meta+539, date w700 + puce + categorie w700 12px MAJabsente+539
extrait+579, 848x61.2absent+579, 848x61
fleche+661, 18.2x20.3-+661
diff pixel contre le live->=29 % (referentiel §C7)18.09 %

Gilliard /blog/ : 32.95 % contre les 33.0 % du referentiel - inchange, la ligne meta partie.

⚠️ Ce qui RESTE sur cette carte, et qui n'est pas la carte : a 375 / 768 / 1024 nos cartes sont respectivement +52 / +42 / +14 trop hautes, et la cause est B3-9 - le corps de PDN garde sa taille desktop (20.4/30.6) la ou le live descend a 16/24.48 @375, 17/26.86 @768 et 17/25.5 @1024. Gilliard et chevaliers ont recu cette correction en cont.21, PDN jamais. Meme origine pour l'ecart de largeur de carte a 375 (355 contre 335) et a 768 (700 contre 708) : la gouttiere du .container de PDN, a mesurer page par page avant d'y toucher.

C11. L'ECHELLE TYPOGRAPHIQUE DE PDN (B3-9) - ce n'est pas le corps, c'est le ROOT ​

B3-9 disait « police de corps en mobile ». La mesure dit plus que ca. Bissection au pixel de largeur sur https://portedenovembre.ch/politique-de-confidentialite/ (la page la plus riche en texte courant), element html et element body :

<480480-767768-10231024-1279>=1280
html (root)1616171717
body16 (1rem)1617 (1rem)1720.4 (1.2rem)
interlignage24.4825.2826.8625.530.6
ratio1.531.581.581.51.5

Deux enseignements que « le corps est trop gros a mobile » ne portait pas :

  1. Le root descend a 16px sous 768. Ce n'est pas un ajustement du corps, c'est tout le systeme rem de la marque qui change de base. Le commentaire du depot (« Live's ROOT font-size is 17px, not 16 ») etait juste - au-dessus de 768 seulement.
  2. Le 1.2rem du live n'arrive qu'a 1280, pas a 1024. Entre 768 et 1279 le corps est a 1rem, donc 17px.

Nous tenions 17px / 20.4px / 30.6 aux cinq largeurs : chaque paragraphe de PDN etait 27 % trop gros a 375 et 20 % a 768. Corrige dans themes/pdn/ uniquement (_bootstrap_variables.scss

  • main.scss) ; gilliard et chevaliers ne bougent pas d'un octet.

Verification. Les six largeurs rendent desormais exactement la paire du live. Porte de structure sur /cocktails/, la page dont la carte vient d'etre refaite :

37576810241440
hauteur live4061456346094383
hauteur locale4030 (-31)4574 (+11)4010 (-599)4303 (-80)

⚠️ Comment lire le diff pixel apres ce changement. Le sweep 375/768/1024 des 20 pages PDN donne un resultat MIXTE, et c'est attendu : reduire le corps change la hauteur de chaque bande, donc tout ce qui suit une bande encore fausse se decale davantage. Les pages dont la structure est juste s'ameliorent nettement (@375 : news 55.5 -> 44.7, news-events 57.5 -> 48.4, cocktails 57.5 -> 49.1, goodies 46.3 -> 39.9, vins 70.2 -> 64.0 ; @768 : privacy 51.4 -> 40.0, home 53.5 -> 46.0). Les pages d'ARTICLE empirent (article-ice-0-0 @375 26.4 -> 41.1) parce qu'elles sont deja beaucoup trop courtes : porte de hauteur sur /new-porte-de-novembre-ice-0-0/, -552 / -292 / -1236 / -668. C'est B3-5 (la bande « Articles récents » absente) et §A3, pas la typographie. Ne pas annuler ce changement sur la foi de ces pages : leur contenu manquant est le defaut, et il se voit maintenant.

C12. L'ECHELLE DE CONTENEUR DE PDN - FLUIDE, pas un escalier Bootstrap ​

Trouvee en mesurant la grille produits : nos tuiles tombaient a cote de celles du live a 375, 768 et 1024 sans que la grille soit fausse - c'est le CADRE qui l'etait. Bissection au pixel de largeur, sur deux pages differentes du live (/goodies/ et /contact/), largeur de CONTENU de .e-con-inner :

fenetre3754004794807681024120012791280135014401920
live335360439420708964114012191100110012901290

Soit fenetre - 40 sous 480, fenetre - 60 de 480 a 1279, puis 1100 fige, puis 1290.

Deux faits qu'un $container-max-widths Bootstrap ne peut pas rendre :

  1. C'est FLUIDE jusqu'a 1280 - aucun palier, la gouttiere est constante et c'est tout ;
  2. le live est plus ETROIT entre 1280 et 1439 (1100) qu'au-dela (1290) - un escalier monotone ne peut pas le decrire.

Notre escalier donnait 355 / 700 / 940 / 1270 : +20 a 375, -8 a 768, -24 a 1024, -20 a 1440. Une erreur sur le cadre est une erreur sur chaque bande de la marque, et plusieurs bandes la compensaient deja une a une (> .container { max-width: 1290px } sur la bande « Détails », 1350 sur le pied). Corrigee a la source ; la gouttiere est desormais portee par le padding du conteneur comme chez le live, et les bandes qui debordent posent padding-inline: 0.

Verification : les 7 largeurs testees rendent la largeur du live au pixel. Sweep PDN :

  • @375, gain large - vins 64.0 -> 60.1, cocktails 49.1 -> 46.0, news-events 48.4 -> 45.7, idees-cadeaux 59.0 -> 56.4, privacy 56.9 -> 54.2, evenements 35.3 -> 34.0 ;
  • @1440, neutre (±0.3 % sur 19 pages sur 20) ;
  • une exception, /contact/ @1440 : 30.9 -> 36.0. Verifie : c'est B3-13, pas le conteneur. La porte de hauteur donne -13 a 375 (donc juste) et +586 a 1440, parce que la bande finale de cette page GRANDIT avec la fenetre chez nous alors que le live est constant a 2545 de 1440 a 1920. Un conteneur plus large nourrit une bande deja fausse.

C13. GRILLE PRODUITS /goodies/ et /idees-cadeaux/ (B3-10, B3-11) - FAIT ​

B3-10 disait « 3 colonnes a 768 contre 2 » et B3-11 « image carree ». Les deux sont vrais, mais c'etait le plus petit des defauts. Capture cote a cote : le live pose des PNG detoures a meme la bande ambre, titre et bouton centres dessous ; nous rendions un PANNEAU BLANC avec l'image recadree en paysage sur un fond gris, le nom du produit imprime DEUX FOIS (le scrape le ramasse comme titre et comme prose, et le generateur ne dedoublonnait que la grille de bouteilles) et le bouton aligne a gauche. Encore §C6 : chaque element existait, aucun n'etait « faux », et aucune sonde par element ne pouvait le dire.

Specification mesuree (tuile ET image, quatre largeurs). La tuile porte 10px de padding et l'image est carree, egale a la tuile moins 20 :

37576810241440
/goodies/ colonnes2333
tuile157.5202.7288376.7
image137.5182.7268356.7
ecart entre colonnes20505080
/idees-cadeaux/ colonnes1222
tuile335334462615
image315314442595
ecart-404060

Ces nombres tombent exactement sur (contenu - (n-1) x ecart) / n depuis que le conteneur suit l'echelle du live (§C12) - c'est ce qui permet de les poser en dur au lieu de compenser. Titre : GothamPro w400 noir, 18px a 375, 22px au-dela, interligne du corps. Bouton : un LIEN, pas notre .btn - 130.4x37, padding 12/24, rayon 3, GothamPro 13px/13 w700 noir sur fond transparent, suivi d'un glyphe fleche de 13px.

Verifie apres : colonnes, x, largeur de tuile et taille d'image identiques au live aux quatre largeurs, sur les deux pages.

37576810241440
goodies, diff pixel40.2 -> 20.660.0 -> 18.939.6 -> 19.944.7 -> 19.6
idees-cadeaux56.4 -> 38.238.8 -> 37.354.4 -> 41.156.3 -> 48.0
goodies, porte de hauteur+16+135-502+76
idees-cadeaux-89+258-393+293

⚠️ NON PORTE, deliberement : le live pose un padding haut different sur chaque rangee d'images (80 / 0 / 36 px a 1440 sur /goodies/) - de l'authoring Elementor, pas une regle. Nos rangees sont regulieres, d'ou une tuile plus courte de 32 a 88px selon la largeur. C'est le residu de hauteur de /goodies/.

C14. B3-2 - L'INTRO EST DANS LE HERO, et la bande de titre varie PAR PAGE ​

B3-2 (« hero + intro ») venait d'un agent et disait juste « hero 541/419/419/335 ; l'intro est DANS le hero ». Re-mesure de premiere main sur /idees-cadeaux/, arbre a l'appui : la bande de titre du live porte, dans UN seul conteneur, un espaceur, le h1, le paragraphe d'intro et un second espaceur. Nous rendions le h1 dans un page-hero puis l'intro dans un richIntroautonome juste dessous.

37576810241440
live, hero + intro465499499621
nous, hero seul425499499686
nous, richIntro en plus+221+301+276+281
total, ecart+181+301+276+346

Sur ONZE pages. ✅ CORRIGE le 2026-08-01 : pdn-gen.mjs pose l'intro de la bande de titre dans heroText (la propriete existait deja sur la composition pageHero, et _pageHero.cshtml la rendait deja) au lieu d'emettre un bloc. Quatre pages portaient reellement une intro de hero : vins, club, idees-cadeaux, goodies.

⚠️ ET VOICI LE PIEGE, mesure : la hauteur de cette bande varie par page chez le live, parce que ses espaceurs Elementor sont saisis a la main. Bas de la bande de titre :

3757681440
/news/, /cocktails/250375595
/vins/425499686
/idees-cadeaux/465499621
/club/496593703
mediane425499621

Aucune regle ne reproduit cette dispersion : ce sont des valeurs d'auteur. On pose la MEDIANE (ecart moyen 40px a 1440 contre 53 avec notre ancien 686). Poser le 465 de /idees-cadeaux/ a 375 - la valeur d'UNE page - a fait reculer quatre pages sur cinq : le piege de portee, encore.

Typographie de l'intro, mesuree : 25/35 a 375, 28/42 des 768, 32/45 des 1280, blanc, GothamPro w400, dans un conteneur centre de 315 / 546 / 751 / 561. Ce n'est pas le corps de la marque, c'est une echelle propre au hero. Boites verifiees apres : 315x105, 546x84, 751x84, 561x90 - identiques au live, aux memes x.

⚠️ Un troisieme piege de portee dans le meme changement : la regle .theme-pdn .page-hero .page-hero__text fuyait sur le hero de detail-vin, dont la regle propre ne redeclare ni margin ni max-width - les sept pages de vin ont recule de ~3 points a 375 avant que le :not(.page-hero--product) ne soit pose.

Resultat, sweep des 20 pages PDN : -27.6 points a 1440 et -60.6 a 375 au total. goodies 44.7 -> 23.2 / 40.2 -> 14.7, idees-cadeaux 56.3 -> 35.9 / 56.4 -> 32.4, accueil 53.6 -> 43.1 a 375, cocktails 18.1 -> 14.1 a 1440. Reculs, tous expliques par la dispersion ci-dessus : club +5.1/+6.0 (sa bande live est la plus haute, 703/496, et il lui manque encore son formulaire de 932px), evenements +3.8, vins +3.7, news-events +2.8, news +2.5, privacy +3.8 a 375.

Ce que ces verdicts changent pour la suite ​

L'historique du depot disait « environ la moitie des trouvailles d'agent sont fausses ». Sur ces trois-la, c'est 3 sur 3. Le mode d'echec est toujours le meme et il est mecanique, pas interpretatif : l'agent mesure le mauvais element, ou dans le mauvais etat, puis rapporte l'absence de mesure comme une absence de propriete. Deux garde-fous en decoulent, a appliquer a toute ligne [AGENT] restante du registre :

  1. Un survol se force sur l'element ET sur ses ancetres. Un ::after a 0px sous a:hover ne prouve rien tant que li:hover n'a pas ete essaye.
  2. « Selecteur sans correspondance » n'est jamais « propriete absente ». Avant de conclure qu'une propriete manque sur le live, verifier que l'element a bien ete trouve.

C15. B2-9 - LA PAIRE DE PHOTOS DE LA BANDE 2 DE L'ACCUEIL (2026-08-03) - FAIT ​

Le live pose deux portraits cote a cote dans la moitie gauche ; pdn-gen.mjs:374 prenait allImgs[0] et jetait le second, parce que la bande porte 2 images + 1 texte et rate donc le test imgs >= 3 de la grille. Mesure de premiere main, quatre largeurs, live contre local APRES :

37576810241440
bande, live / nous641 / 641418 / 417455 / 454562 / 562
photo 1163x278 @20 / exact149x256 @50 / exact213x365 @50 / exact270x462 @135 / exact
photo 2@193 / exact@220 / exact@284 / exact@435 / exact
titre335x56 @20,378 / exact319x70 @399,110 / 109447x70 @527,142 / 141480x114 @840,186 / exact
corps335x90 @20,459 / exact319x78 @399,205 / 204447x52 @527,237 / 236480x70 @840,325 / 326
bouton150x47 @113,574 / exact167x50 @399,308 / exact167x50 @527,314 / exact179x55 @840,420 / exact

Trois faits que la ligne B2-9 du registre ne portait pas, et qui changent l'ordre de valeur :

  1. Le live passe en DEUX COLONNES des 768 ; nous empilions jusqu'a 1440. Cout reel +418 @768 et +552 @1024, vingt fois le +21 visible a 1440 - la seule largeur ou la ligne d'origine avait regarde.
  2. A 375 le live met la PAIRE AU-DESSUS du texte ; notre rangee generique mettait le texte d'abord.
  3. Le rapport des photos est constant (270/462) aux quatre largeurs : la paire est mise a l'echelle, jamais recadree par palier.

Trois pieges de mesure rencontres dans cette seule bande :

  • ⚠️ « Le live n'a pas de bouton » - faux. La premiere sonde cherchait a.elementor-button, a.btn ; le live utilise a.sc_button. Agir sur ce constat aurait supprime un bouton reel. C'est le garde-fou n°2 ci-dessus, en situation.
  • ⚠️ La MAJUSCULE du libelle n'est visible qu'a la capture. Le <a> calcule text-transform: none : le live la porte sur un span.sc_button_title interne (avec 0.96px d'interlettrage). Toutes les sondes par element passaient au vert sur « NOS VINS » contre « Nos vins ». §C6, encore.
  • ⚠️ Une bande « manquante » de 1209px qui n'existe pas. 6b43e64 (« Johannisberg ») est la grille de vins imbriquee dans la bande « Découvrez » : le selecteur de bandes comptait le parent ET l'enfant. Verifier l'ascendance avant de declarer une bande absente.

C16. ⚠️ LE DIFF PIXEL DE L'ACCUEIL PDN N'EST PAS DETERMINISTE - NE PAS L'UTILISER COMME PORTE ​

Mesure du 2026-08-03, meme build, meme largeur, trois passes : 375 a rendu 49.40 / 49.40 / 38.33 %. Onze points d'ecart sans une ligne de code changee. La cause est celle que config.js decrit deja pour le hero : le live fait tourner une diapositive differente a chaque chargement, et le masque ne couvre pas tout ce qu'elle peint.

Consequence pratique : le pourcentage de pixels de pdn/home ne prouve NI une regression NI une amelioration. Un ecart de moins de ~11 points sur cette page est du bruit. Ce qui porte cette page, ce sont les mesures par bande contre le live et la porte locale baseline.mjs.

⚠️ Corollaire : le 43.1 @375 consigne a la session precedente et le 49.4 mesure ensuite ne sont pas comparables. Comparer un nombre note a un nombre mesure est exactement l'erreur que measure-never-trust-a-commit-message documente - ici elle aurait fait chasser une regression inexistante.

C17. B3-14 - LA COULEUR DU TEXTE COURANT DE PDN (2026-08-03) - FAIT ​

--g-gray: #4a4a52 etait un gris fonce plausible, jamais mesure - la note d'origine ne revendiquait d'ailleurs que « le corps n'est plus invisible », pas « c'est la bonne couleur ». Mesure du live le 2026-08-03, sur chaque consommateur du jeton avant d'y toucher :

elementpagelive
prose 20.4px/cocktails/, /contact/, confidentialite, articlergb(0,0,0)
date + categorie de carte, 14px/cocktails/rgb(0,0,0)
texte des champs de formulaire/contact/rgb(0,0,0)
titre de carte/cocktails/rgb(17,19,26) - jeton de titre, distinct

Aucun consommateur ne peint gris : le jeton entier bascule, plutot que de detacher les regles de prose. Pose comme $pdn-ink-light dans le fichier de variables du theme (regle #11 : la couleur se declare UNE fois) et consomme aussi par --g-heading, qui la codait en dur.

⚠️ Le pourcentage de pixels ne bouge presque pas (confidentialite 40.5 -> 40.4, cocktails 14.1 inchange) et c'est attendu : une couleur ne touche que les pixels des glyphes, et sur la confidentialite le texte reste decale verticalement tant que B3-3 (nos H2 57.12px contre les H3 38.39px du live) n'est pas corrige. La preuve de cette correction est la couleur calculee identique des deux cotes, pas le diff pixel. Porte de portee : gilliard 110/110 et chevaliers 60/60 identiques a ref-20260803 - le jeton est bien enferme dans .theme-pdn main.

C18. B3-1 - LE FORMULAIRE D'ADHESION DE /club/ (2026-08-03) - FAIT ​

La cause n'etait pas un defaut de style : la bande disparaissait. Le live ne pose pas un shortcode CF7 ici, il depose un embed Mailchimp dans un widget html, qu'aucune branche de bandToBlock ne reconnaissait. La bande retombait sur la regle de prose et emettait un richIntro au corps vide. On porte le JEU DE CHAMPS rendu, jamais l'embed, et le bloc garde son contrat inerte : pas de POST de l'adresse et de la date de naissance d'un visiteur vers un tiers.

Mesure sur le live, quatre largeurs, live contre local APRES :

37576810241440
formulaire335x598 / 335x601326x608 / 326x610480x581 / 480x582616x581 / 616x582
x20 / exact387 / exact489 / exact674 / exact
conteneur de bande (live)335 @20678 @45934 @451160 @140
bouton335x52 @546 / 549326x52 @556 / 558480x52 @529 / 530616x52 @529 / 530

Bande du formulaire : 602 contre les 601 du live a 1440. B3-1 est clos.

Faits mesures qui ne se deduisent d'aucune regle :

  • La bande a son propre conteneur (335/678/934/1160), plus etroit que l'echelle de conteneur de PDN (1350 a 1440). Centre, il retombe sur les x du live aux quatre largeurs.
  • Les champs passent a deux colonnes seulement a partir de 1024, alors que la BANDE est deja en deux colonnes des 768. Les deux paliers sont independants.
  • Le pas est de 43 partout sauf 40 avant la rangee NPA/localite, et de 55 avant le bouton.
  • Les largeurs du titre (335/212/314/404) sont auteurs : ce sont elles qui decident des retours a la ligne, donc de la hauteur de la colonne de gauche.
  • Le « * indicates required » du live est display:none : ne pas le reproduire.

⚠️ Deux defauts vus SEULEMENT a la capture de bande, invisibles a toute sonde geometrique : notre titre sortait en capitales (le live est en casse normale), et le live imprime de vrais separateurs " /" entre les trois champs de date. §C6, une troisieme fois dans la meme session.

⚠️ Le « 932px manquants » du registre etait perime. Mesure du jour : la page est 658 courte a 1440, et apres le formulaire le reste ne releve plus de B3-1 - c'est la bande « Comme Malorie Blanc » (-141) et « Profitez d'avantages » (-380).

Portee : gilliard 110/110 et chevaliers 60/60 identiques a ref-20260803 malgre l'edition de base/_form-block.scss ; les formulaires de /contact/ des deux marques gardent leur habillage d'origine (bouton 300x83 et 434x46, champs a bordure complete). Dette : ce variant est un preset CODE EN DUR de plus, que la phase 2.3 doit convertir en formField comme les cinq autres.

C19. B3-3 + B3-4 - LA PAGE DE CONFIDENTIALITE N'EST PAS UNE SUITE D'INTROS (2026-08-03) - FAIT ​

Le registre decrivait un defaut de taille de titre. La mesure en a trouve six, et ils n'ont qu'une cause : nous rendions une page de TEXTE COURANT avec le composant "intro de section".

Le declencheur est dans les donnees, pas dans une liste de slugs. Sur les 14 pages Elementor du scrape, /politique-de-confidentialite/ est la seule dont h1 vaut "" et la seule dont les titres de bande sont des h3 (les 13 autres portent h1 + h2). Le generateur lit ces deux signaux ; aucun slug n'est code en dur.

livenous (avant)
bande de titreAUCUNE - le contenu commence sous l'en-tetepage-hero de 560px, h1 de 150px
alignementa gauchecentre
colonne de prosele conteneur entier (1290 a 1440)716 (la colonne 7/12 de Gilliard)
titre38.39/38.39, marge 0 0 3057.12/57.12, marge 0 0 60
souligne du titreaucuntrait de 100px centre
marge de paragraphe0 0 1.8em, et 0 sur le dernier1em en haut ET en bas, dernier compris
interlignage du corps24.48 / 26.86 / 25.5 / 30.624 / 25.5 / 25.5 / 30.6

Structure du live : [espaceur] [titre + texte] [espaceur] ... [espaceur], dans un page_content_wrap qui porte le rythme haut/bas. Bissection au pixel de largeur (375, 479, 480, 600, 767, 768, 900, 1023, 1024, 1100, 1279, 1280, 1350, 1440, 1600, 1920) :

fenetre<480480-767768-10231024-10991100-12791280-1439>=1440
titre182025282838.392838.3928
marge sous titre30303030303030
espaceur de bande40406060808080
rythme haut/bas5060809090100119
marge de paragraphe161617171736.7236.72

Les paliers du titre (480/768/1024/1280) et ceux de l'espaceur (768/1100) sont independants : aucune echelle unique ne les decrit, ce sont des valeurs d'auteur Elementor.

Verification - chaque paragraphe de la page tombe au y du live :

37576810241440
y des 6 premiers paragraphes, live156/539/653/792/929/1304195/400/471/568/710/986208/378/446/514/658/878267/457/524/622/801/1072
ecart local-1 sur deux d'entre eux, 0 partout ailleurs000

Bandes @1440, espaceur compris : 534/534, 271/271, 399/399, 369/369 - exactes. La cinquieme ("Quels types de cookies") fait 852 contre 1560, et tout l'ecart est le tableau d'inventaire des cookies du plugin WordPress : hauteur mesuree du widget 2177/1211/698/678, contre un ecart de contenu de 2209/1242/727/708 aux memes largeurs. §C3 avait deja tranche que ce tableau decrit des plugins que nous ne faisons pas tourner et ne doit pas etre porte.

Trois enseignements qui depassent cette page :

  1. .rich-intro__body figeait line-height: 1.5 - le ratio de Gilliard. PDN en a trois (1.53 / 1.58 / 1.5, §C11). Le theme portait deja la bonne echelle sur body, mais une declaration de classe bat toujours l'heritage : le bloc rendait 25.5px la ou le live fait 26.86 a 768. Corrige par line-height: inherit, pour TOUT .theme-pdn .rich-intro__body. §C11 annoncait "les six largeurs rendent exactement la paire du live" : c'etait vrai du body, faux de ce bloc. Une verification au niveau du token ne prouve rien sur un composant qui redeclare la propriete.
  2. Le repli p.h1 || p.name || slug INVENTAIT une bande de titre. Le scrape disait "" ; le repli a transforme une donnee juste en 560px de defaut. Un repli silencieux sur une mesure vide est un mensonge par defaut.
  3. main:has(.page-hero) servait de test "page interieure" pour le degrade rose->ambre. Retirer le hero d'une page interieure lui retirait son fond. Un selecteur structurel qui sert de proxy pour une intention doit etre relu chaque fois que la structure bouge.

⚠️ Vu a la capture, non corrige et consigne en dette : (a) notre degrade de page interieure s'arrete a 686px fixes alors que le live pose linear-gradient(#FC8DA3 16.18%, #FFCC66 34%), donc en pourcentage de la hauteur de la bande - visible sur cette page, ou le live reste rose bien plus bas ; (b) au defilement le live peint une barre d'en-tete fixe que nous ne peignons pas (les deux header mesurent position:absolute et sortent de l'ecran a l'identique : la barre du live est un CLONE, element distinct, non identifie) ; (c) le pied de PDN fait 1225 contre nos 668 a 1024 (B2-7, deja ouvert).

⚠️ La page n'a plus de <h1>, parce que le live n'en a pas. Le titre de bande reste un <h2> la ou le live pose un <h3> : c'est desormais le premier niveau de la page, donc le choix accessible, et aucun pixel n'en depend.

Porte. baseline.mjs --against ref-20260803b : gilliard 110/110 et chevaliers 60/60 identiques - le variant et l'inherit sont enfermes dans themes/pdn/, base/ n'est pas touche. Le bloc n'existe que sur 3 pages de PDN (grep du HTML rendu : confidentialite 5, les 2 articles 2 chacun, zero ailleurs).

ATTENTION le pourcentage de pixels ne peut pas porter cette page, pour une raison structurelle differente de celle de l'accueil (§C16) : le tableau de cookies non porte fait 678px a 1440, donc tout ce qui le suit est decale d'autant et compte comme different. Mesure du jour : 41.9 / 44.9 / 52.8 / 55.2 %. Ce qui porte la page :

avantapres
hauteur du document a 1440 (live 3986)5578, soit +15923313, soit -673
dont explique par le tableau du plugin--678
y des titres a 1440 (live 199/733/1004/1403/2963)721/1696/2278/3002/4328identiques au live

Et le registre de noeuds de diff.mjs --report-only le confirme : sur les 60 noeuds du live absents chez nous a 1440, il n'y en a aucun dans la zone de prose - ce sont les th/td du tableau du plugin (pll_language, cookielawinfo-checkbox-*, _ga, _gid, _gat_gtag_UA_6881176_1), le PIED (logo PDN 294x69, logo Gilliard, colonne adresse, colonne de liens = B2-7) et les deux liens d'evitement du live.

C20. LES DIX ARTICLES DE PDN RENDAIENT LEUR CORPS DEUX FOIS (2026-08-03) - FAIT ​

Signale par un agent de mesure, re-verifie de premiere main avant d'agir : grep rich-intro__body sur le HTML rendu donne 2 sur chacune des deux pages d'article du harnais, et la capture montre le meme paragraphe peint deux fois.

Cause, dans pdn-gen.mjs : pour un renderer: "theme-post" le generateur emettait les deux - les bandes classees (une par bande, propres) et le p.post.html verbatim. Cette seconde copie etait aussi la seule chose du depot qui violait le contrat pose en tete du fichier ("WE PORT THE RENDERED RESULT, NOT ELEMENTOR") : elle portait data-elementor-type et les classes elementor-element sur les dix articles.

Verifie mot a mot sur les dix avant de retirer quoi que ce soit : la classification par bande couvre l'integralite du post.html, au titre pres (que le bloc porte deja en title) et au BOUTON pres. Six des dix ferment leur corps par un bouton ("Acheter" x4 vers la boutique Gilliard, "Découvrir", "Plus d'infos" vers gilliarday.ch) que bodyHtmlOf ne lisait pas - il ne survivait que dans la copie brute. richIntro gagne donc un ctaLink, et classify lit le trx_sc_button.

Le bouton : l'element exterieur ment DEUX fois, et les deux mensonges se voient.

ce que dit a.sc_buttonce qui peint
cassetext-transform: nonespan.sc_button_title : uppercase
policefont-family: Krona Onespan.sc_button_title : GothamPro, letter-spacing: 0.96px

Course de glyphes mesuree sur le live (Range.getBoundingClientRect sur le noeud texte) : 76.08px. Une sonde temoin injectee dans la page du live donne 87.38px pour le meme mot en Krona One 14px - exactement ce que nous rendions, d'ou une boite de 189 contre 176. Le texte source est bien "Acheter" : la majuscule est un RENDU, pas une donnee, et on n'ecrit donc pas "ACHETER" en base. Apres correction : 176.1 x 55.0 contre les 176.1 x 55 du live.

C'est la troisieme ET la quatrieme occurrence de §C6 dans la meme journee. Le mode d'echec ne varie pas : lire l'element exterieur, et prendre ce qu'il calcule pour ce qui est peint.

ATTENTION la page est desormais PLUS COURTE que le live, et c'est correct : -545 / -534 / -1596 / -1214 aux quatre largeurs. Le doublon comblait un trou qui existait deja (§C11 mesurait deja -552 / -292 / -1236 / -668 le 2026-08-01, doublon compris). Ce qui manque est connu et chiffre : la bande "Articles récents" (B3-5, ~616 a 1440 marge comprise) et la bande d'en-tete d'article du live (sur-titre de categorie + photo a la une 848x600 centree). Ne pas lire ce raccourcissement comme une regression : il rend visible un defaut qui etait masque.

C21. B3-7 et B3-12 - LE REGISTRE DECRIT UN SEUL FORMULAIRE SUR TROIS, ET SE TROMPE SUR LE BOUTON ​

Mesure d'agent, dont les deux affirmations decisives ont ete verifiees a la capture de premiere main avant d'etre consignees. Non corrige - c'est la specification du prochain lot.

B3-12 "texte blanc sur fond transparent, bordure #C699FB -> #BB85FA au survol" est FAUX comme APPARENCE. Ces couleurs sont bien les border-*-color calculees, mais border-width vaut 0px et border-style vaut none : rien n'en peint jamais. Capture du live a l'appui, le bouton d'envoi de /contact/ est un rectangle NOIR plein (span.submit-style-in, 174.6x55, position:absolute, z-index:0, fond rgb(0,0,0)) avec un texte blanc Krona One et une icone d'avion en papier. Le survol reel est ce fond noir qui passe a rgba(0,0,0,0.69).

B3-7 ne vaut que pour /contact/, et son mecanisme est ailleurs. Le champ est bien transparent et sans bordure visible, mais sa border-bottom-color est rgba(0,0,0,0) : le trait noir est un element FRERE, span.line (307.5x1, transition 0.4s). Et la capture montre ce que nulle sonde geometrique n'avait releve : chaque champ porte une icone fontello en ::before de span.style-line.icon-* - c'est a quoi sert le padding-left: 36px. Les libelles sont des placeholders ("Nom et prénom", "Adresse e-mail", "Téléphone", "Sujet", "Message..."), les <label> sont vides, et le formulaire passe a deux colonnes des 601px.

Les deux autres surfaces ne suivent PAS cette description :

surfaceliveverdict sur le registre
/club/deja transparent + filet bas noir des deux cotes, boites a 1px presFAUX : ce n'est pas un defaut d'habillage. Restent le placeholder (rgb(0,0,0) a 1 contre rgb(17,19,26) a 0.7), le padding-left des champs pleine largeur, la trio de date centree a letter-spacing: 1px, et le palier deux colonnes a 769 chez le live contre 1024 chez nous
pied, newsletterboite BLANCHE pleine, sans bordure, bouton rose #FC8DA3 a texte noir (survol -> or #FFCC66)FAUX dans les deux sens : nous sommes deja blanc/rose. Les vrais ecarts sont la hauteur (54 contre 48), le placeholder "Votre e-mail" totalement absent chez nous, et un effondrement de la colonne a 98-338px entre 992 et 1199 la ou le live fait 964

Et le plus gros : /contact/ n'est pas un probleme d'habillage, c'est un formulaire DIFFERENT. Live : 5 controles, 4e champ "Sujet", pas de case de consentement, bouton "Envoyer", colonne de 645 a x671. Nous : 4e champ "Adresse", une case de consentement en plus, bouton "ENVOYER MON MESSAGE", colonne de 873 centree a x284. Corriger l'habillage seul ne fermera pas cette page.

ATTENTION piege de sonde releve au passage : le live applique une animation d'apparition au defilement. label[for="mce-BIRTHDATE-month"] calcule visibility: hidden tant qu'il est hors champ. Toute sonde qui lit un style calcule sans avoir amene l'element dans le viewport rapportera des elements "caches" qui ne le sont pas.

C22. LE "CHAMP NEWSLETTER DU PIED" N'EST PAS UN DEFAUT D'HABILLAGE - C'EST LA GRILLE DU PIED (B2-7) ​

En allant construire la moitie "pied" de B3-7, la mesure a deplace le defaut. Verifie de premiere main, sur /cocktails/ (le pied est le meme sur toutes les pages) :

fenetrechamp, livechamp, nous
960900 @x30928 @x16
992932 @x3098 @x878
1024964 @x30130 @x878
1080350 @x700186 @x878
1199396 @x773305 @x878
1440473 @x907473 @x907

Notre champ tombe a 98px de large a 992 et ne retrouve le live qu'a 1440. C'est visible sur toutes les pages de la marque entre 992 et 1440.

Deux causes, et aucune n'est de l'habillage :

  1. Le palier. Le pied du live passe en colonnes a 1025 ; le notre a 992. Bissection : 768 et 1024 empiles pleine largeur, 1025 en 4 colonnes.
  2. La grille est FLUIDE chez le live et FIGEE chez nous. Rangee e-con-inner, gouttiere de 40px constante, quatre colonnes :
fenetreconteneurlogoadresseliensnewsletter
1025965 @x30226188103328
10801020 @x30241200110350
12001140 @x30272227124397
12801220 @x30293244134427
14401350 @x45324270148473
19201350 @x285324270148473

Nos trois premieres colonnes sont figees a 324 / 270 / 148 a toutes les largeurs - les valeurs du live A 1440 - et la newsletter absorbe le reste. D'ou le filet : a 1024 les trois fixes mangent 642 d'un conteneur de 992, il ne reste que 130. C'est la meme erreur que §C12 (une valeur juste a une largeur, figee partout) mais sur le pied.

Le conteneur suit fenetre - 60, plafonne a 1350. A 1440 les colonnes se figent aussi (324/270/148/473 = 1215, plus 120 de gouttieres = 1335 dans 1350 : 15px de mou en fin de rangee), ce qui interdit un modele en pourcentages purs.

Cela ferme la moitie "pied" de B3-7 en la reclassant : le pied n'a pas de defaut d'habillage (il est deja blanc/rose comme le live, §C21). Il a un defaut de GRILLE, qui appartient a B2-7, et c'est aussi lui qui explique le pied a 1225 contre nos 668 a 1024 consigne en §C19.

Deux ecarts d'habillage subsistent, eux, et sont independants de la grille :

  • le champ du live porte placeholder="Votre e-mail" ; le notre n'a aucun placeholder (un label.visually-hidden seulement), donc une barre blanche vide ;
  • hauteur 54 contre 48, qui vient entierement du padding : 15px 10px contre 12px 15px.

ATTENTION #mce-EMAIL existe en TROIS exemplaires sur chaque page du live (deux copies de popup a 0x0). Une sonde qui prend querySelector mesure une copie cachee et rapporte 0@x0 a toutes les largeurs - ce qui se lit comme "le live n'a pas de champ". Toujours filtrer sur la visibilite. Ce piege m'a donne un tableau entierement a zero avant d'etre repere.

C23. PHASE 2.2 - LA MOITIE "RESTANTE" N'EST PAS UNE MIGRATION, C'EST UNE SUPPRESSION ​

Le plan decrivait 2.2 comme "creer une composition factsPanel portant facts, l'appliquer a product, vacancy, activity, event, puis supprimer les 6 proprietes d'affichage". Mesure du 2026-08-04, avant d'ecrire une ligne : la premiere moitie de cette phrase construirait un doublon de quelque chose qui marche deja.

  1. factsPanel n'est PAS une composition, c'est un ELEMENT (IsElement: true), donc un BLOC. Il est deja utilise : la bande "Détails" des 7 pages de vin de PDN en est faite, et elle rend ses 7 lignes en 2 colonnes (verifie sur /vins/ice-pdn/ : 7 facts-panel__row, 2 facts-panel__col). C'est le resultat valide en §C8. Le composer sur quatre doctypes aurait pose un SECOND mecanisme a cote de celui qui fonctionne.
  2. Les 6 proprietes d'affichage de productFacts ne sont ecrites NULLE PART. Comptage sur SetValue("alias" et sur les dictionnaires de blocs ["alias"] dans tous les seeders : zero pour appellation, nez, bouche, analyse, idealAvec, garde et ficheProduit. idealAvec n'apparait nulle part dans le depot. Les seules occurrences dans pdn-gen.mjs sont une table de correspondance libelle -> slug d'icone (:117), qui sert justement a construire les blocs factItem.
  3. Aucune marque n'instancie le doctype product : FindOrCreate(..., "product" = 0 (vacancy 1, event 1, activity 0).
  4. Consequence : _pageFacts.cshtml ne rend RIEN, sur aucune marque. Ses lignes sont filtrees sur "valeur non vide", et aucune valeur n'existe. Verifie sur le HTML rendu des trois marques : 0 occurrence de product-facts et de activity-facts. activityPrice et activityLocation sont dans le meme cas (0 ecriture).

Ce qui reste de 2.2 est donc : supprimer du schema mort et du code mort - les 6 proprietes d'affichage de productfacts.config, et le partial _pageFacts.cshtml avec ses 6 libelles codes en dur et ses 7 Model.Value<string>("alias"). Pas de migration de contenu, pas de composition a creer, aucun risque de perte : il n'y a rien dedans.

ATTENTION c'est une modification du CONTRAT UPSTREAM, pas un nettoyage de projet. product, productFacts et activityFacts sont de l'echafaudage du GABARIT : ils sont morts sur ces trois marques, pas necessairement sur un projet aval qui aurait, lui, rempli ces champs. La regle #7 dit de ne pas casser le contrat upstream. La suppression est donc a arbitrer, pas a faire en passant. Garder dans tous les cas les champs qui portent de la LOGIQUE : startDate/endDate (tri), applyEmail (mailto), closingDate, location.

C'est le meme mode d'echec que la fausse dette overlay du 2026-08-03, dans l'autre sens : une note de plan decrivait un travail qui n'existait pas. Un plan est une hypothese au meme titre qu'un message de commit.

Suppression executee le 2026-08-04. Arbitrage rendu par l'utilisateur : on supprime.

supprimegarde
productfacts.config en entier (ses 6 proprietes etaient toutes de l'affichage) -> pierre tombale <Empty ... Change="Delete" />, et la composition retiree de product.configles 4 interrupteurs de activityFacts (activityIcon, hideBooking, showContactCta, contactCtaLabel) : eux aussi sans lecteur, mais ce sont des COMMUTATEURS DE COMPORTEMENT, pas de l'affichage duplique. Les retirer serait supprimer une fonctionnalite, pas du code mort
activityPrice et activityLocation de activityfacts.config (le partial supprime en etait le seul lecteur)tous les champs porteurs de logique ailleurs : startDate/endDate, applyEmail, closingDate, location
_pageFacts.cshtml en entier, et son appel dans ContentPage.cshtml:14

Chaque alias a ete verifie comme n'ayant qu'un seul lecteur (_pageFacts.cshtml) avant suppression, et aucun modele genere n'etait reference hors de umbraco/Models. Apres cycle ModelsBuilder : ProductFacts.generated.cs a disparu, ActivityFacts ne porte plus que ses 4 interrupteurs. Aucune SCSS ne visait .product-facts / .activity-facts - rien a nettoyer la.

Porte : changement non visuel (le partial ne peignait rien), donc baseline.mjs contre ref-20260803b, zero pixel exige sur les trois marques.

ATTENTION la porte de ce commit a d'abord ete passee contre une reference PERIMEE, et c'est une erreur de methode a ne pas repeter. ref-20260803b a ete prise AVANT les deux commits visuels par construction de la veille (la page de confidentialite, §C19, et le doublon des articles, §C20). La comparer a l'etat du jour a donc signale 15 "regressions" qui sont exactement privacy x5 + article-cucumber x5 + article-ice-0-0 x5 - les trois seules pages que ces deux commits changeaient volontairement. Une reference n'est valide que jusqu'au prochain changement visuel ; apres, elle ment.

Preuve que la suppression, elle, ne change rien :

  • le partial supprime ne peignait rien AVANT (0 product-facts / activity-facts dans le HTML rendu) et ne peint toujours rien APRES, verifie sur les 3 marques plus /evenements/ ;
  • il etait appele depuis ContentPage.cshtml, donc par TOUTES les pages de contenu : s'il avait rendu quoi que ce soit, la porte aurait signale des dizaines de pages, pas exactement les trois deja modifiees la veille ;
  • les trois pages signalees rendent toujours ce qui avait ete verifie avant la suppression (confidentialite 5 blocs de prose / 0 hero, articles 1 corps + 1 CTA) ;
  • la bande "Détails" de PDN, faite du BLOC factsPanel, rend toujours ses 7 lignes.

Nouvelle reference locale posee apres coup : ref-20260804.

C24. PHASE 2.4a - LE SNIFF <strong> D'Event.cshtml : LE COMPORTEMENT EST BON, LE COMMENTAIRE EST FAUX ​

Mesure du 2026-08-04, avant de toucher au code. Le plan resumait ce point par "un editeur qui met un mot en gras fait disparaitre dates et lieu". C'est vrai comme CONSEQUENCE, mais le code est DELIBERE, et aujourd'hui il produit le bon rendu.

Event.cshtml:34 : introCarriesFacts = introHtml.Contains("<strong"). Quand c'est vrai, la liste derivee (Dates : / Lieu :) n'est pas rendue, au motif que l'intro porte deja les faits.

Le commentaire du fichier se trompe de marque. Il affirme que le cas "intro qui porte les faits" est celui de gilliard et que "chez chevaliers l'intro est de la prose simple, donc la liste derivee reste". Comptage : 25 des evenements de chevaliers portent un <strong> dans leur intro - c'est donc chez CHEVALIERS que le sniff se declenche le plus souvent.

Et il a raison de se declencher. Texte rendu, live contre local, sur https://chevaliers.ch/fr/event/caves-ouvertes/ :

CAVES OUVERTES
Bienvenue aux caves ouvertes des Domaines Chevaliers...
Dates
13, 14 & 15 mai 2021
11h00 - 18h00
INFORMATIONEN
Degustation, achat direct, visite de cave, Bar a vin, raclette
RETOUR AUX EVENEMENTS

Les deux cotes rendent ces lignes a l'identique. Le live porte bien "Dates" et les horaires, mais dans le corps de l'intro, pas dans une liste derivee - et notre sniff les laisse passer sans doubler. event-facts compte 0 sur cette page chez nous, ce qui est le resultat juste.

Le defaut n'est donc pas le rendu d'aujourd'hui, c'est le MECANISME : deviner l'intention d'un editeur en reniflant une balise. Un editeur qui met en gras un mot quelconque dans une intro qui ne porte PAS les faits perd silencieusement dates et lieu. C'est exactement le genre d'implicite que la phase 2 existe pour rendre explicite.

Correction retenue (a faire) : une propriete booleenne sur la composition scheduleFacts - "les dates et le lieu sont deja dans l'introduction" - posee a true sur les pages ou le sniff est vrai aujourd'hui, pour que le rendu reste identique au pixel, et false par defaut. Porte : non visuel -> zero pixel.

L'autre moitie de 2.4a, elle, est un vrai bug sans nuance : Event.cshtml:18 fige CultureInfo.GetCultureInfo("fr-FR") pour formater les dates, quelle que soit la culture de la requete. Inoffensif tant qu'une seule langue existe, faux des l'arbre allemand (phase 6).

Contributors

No contributors

Changelog

No recent changes